Topic
  • 2 replies
  • Latest Post - ‏2008-04-01T19:20:14Z by SystemAdmin
SystemAdmin
SystemAdmin
280 Posts

Pinned topic clone a defct , but want cloned defect to be in Assigned state

‏2008-03-25T21:32:16Z |
After cloning defect want the new defect to come up in the assigned state.
Can some one help.
Below is part of the clone.prompt I have My clone.promt is same as default onew.. Tried to do : set Old-status A , but did not work. Kindly guide.

Status: if not projassert -o $Project
echo "$Submitter-path $Identifier"
sed "s/.....\$/ $Cloner-host!ddts/"
set Submitter-path "$$"
set Old-status $Status
echo S
else
if not null "$Class"
and not equal "$Class" "$New-class"
set Old-status $Status
echo N
fi
fi

set Cloned-from-class $Class
set Class $New-class
unset New-class
unset Parents
unset Children
Updated on 2008-04-01T19:20:14Z at 2008-04-01T19:20:14Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    280 Posts

    Re: clone a defct , but want cloned defect to be in Assigned state

    ‏2008-04-01T19:18:06Z  
    The short answer is this:

    Status: echo "A"

    But that makes a bunch of assumptions on your DDTs setup, namely that you have only one DDTs site.

    The default clone prompt has a rather complex logic because it does not make that assumption. Here's what the default clone.prompt's Status logic is doing:

    -is the project owned on this site? (thats what projassert is checking)
    (no):
    - update the Submitter-path field to include THIS site and its hostname!ddts
    - why are you storing "A" into Old-status? why not just capture "$Status" like the default clone.prompt?
    - set the new (i.e. the clone's) status as "S"
    (yes):
    - if there is a new class and its not the same as the old one,
    then set the clone's state to New.

    The reason for the "S" in the case of multiple sites is that the owning site always has final say over whether or not the new (i.e. the clone) is OK. Once the owning site runs the clone (in its pseudo state "S") through the master.tmpl validation logic, it will update the state to [N]ew and send the udpated copy back to this site.

    If you only have one site, then there's no need for this stuff.
    Just check for old vs. new project and class and set the new state. Capturing the old state and project really is optional (we prefer to simply capture the old identifier as the new record's "Cloned-from", and update the old record's "Clones" field with the new record's id).)

    Its also worth pointing out that the default clone prompt looks at the old and new classes. If they're different the new clone is moved back to New. If the record is being cloned into the same class, then it RETAINS its existing state (which may or may not be what you want).
  • SystemAdmin
    SystemAdmin
    280 Posts

    Re: clone a defct , but want cloned defect to be in Assigned state

    ‏2008-04-01T19:20:14Z  
    The short answer is this:

    Status: echo "A"

    But that makes a bunch of assumptions on your DDTs setup, namely that you have only one DDTs site.

    The default clone prompt has a rather complex logic because it does not make that assumption. Here's what the default clone.prompt's Status logic is doing:

    -is the project owned on this site? (thats what projassert is checking)
    (no):
    - update the Submitter-path field to include THIS site and its hostname!ddts
    - why are you storing "A" into Old-status? why not just capture "$Status" like the default clone.prompt?
    - set the new (i.e. the clone's) status as "S"
    (yes):
    - if there is a new class and its not the same as the old one,
    then set the clone's state to New.

    The reason for the "S" in the case of multiple sites is that the owning site always has final say over whether or not the new (i.e. the clone) is OK. Once the owning site runs the clone (in its pseudo state "S") through the master.tmpl validation logic, it will update the state to [N]ew and send the udpated copy back to this site.

    If you only have one site, then there's no need for this stuff.
    Just check for old vs. new project and class and set the new state. Capturing the old state and project really is optional (we prefer to simply capture the old identifier as the new record's "Cloned-from", and update the old record's "Clones" field with the new record's id).)

    Its also worth pointing out that the default clone prompt looks at the old and new classes. If they're different the new clone is moved back to New. If the record is being cloned into the same class, then it RETAINS its existing state (which may or may not be what you want).
    or, to summarize my somewhat pedantic reply, use this:

    Status: echo "A" <-- this is the state of the new record
    set Old-Status "$Status" <-- this saves the state of the old one for posterity.