Want to modify workflow so RESOLVED isn't a mandatory transition state for everything

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Want to modify workflow so RESOLVED isn't a mandatory transition state for everything

KRAUS, LAURIE A (ATTCORP)
In the Bugzilla 3.6.4 Administration, I want to customize the workflow
to be close to what we are currently use using with our current bug
tracking process. The RESOLVED state is checked off as being an option
from all other states and it is grayed out so you can't uncheck it.

What is the reason for this? Is there a way to change this? For example,
we have a state called DELIVERED after the bug has been resolved, which
is when several bugs are packaged in a build and is delivered to System
Test.  RESOVED isn't a valid state to transition to from DELIVERED>

Laurie Kraus
Senior Technical Architect, at&t


_______________________________________________
support-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [hidden email] in the To: field when you reply.
Reply | Threaded
Open this post in threaded view
|

RE: Want to modify workflow so RESOLVED isn't a mandatory transition state for everything

Tosh, Michael J
KRAUS, LAURIE A (ATTCORP) wrote:
> In the Bugzilla 3.6.4 Administration, I want to customize the workflow
> to be close to what we are currently use using with our current bug
> tracking process. The RESOLVED state is checked off as being an option
> from all other states and it is grayed out so you can't uncheck it.
>
> What is the reason for this? Is there a way to change this? For example,
> we have a state called DELIVERED after the bug has been resolved, which
> is when several bugs are packaged in a build and is delivered to System
> Test.  RESOVED isn't a valid state to transition to from DELIVERED>

Is resolved set as your status for DUPLICATE?  If so, then you have to enable it so that a bug can always get to RESOLVED/DUPLICATE.

There should be a note explaining this, and how to fix it, at the bottom of the workflow chart.  I set my bz to use REJECTED for duplicates, and here is the text:
When an issue is marked as a duplicate of another one or is moved to another installation, the issue status is automatically set to REJECTED. All transitions to this issue status must then be valid (this is the reason why you cannot edit them above).


_______________________________________________
support-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [hidden email] in the To: field when you reply.
Reply | Threaded
Open this post in threaded view
|

RE: Want to modify workflow so RESOLVED isn't a mandatory transition state for everything

KRAUS, LAURIE A (ATTCORP)
Thanks. I went to the Parameters page and the only choices it gave me
for duplicates were RESOLVED and CLOSED. But I have been playing with
the workflow in my sandbox version so I don't know if this impacted my
choices. What determines what are valid choices? I did look at the
documentation, but couldn't find anything on this.

Laurie Kraus
Senior Technical Architect, at&t


-----Original Message-----
From: Tosh, Michael J [mailto:[hidden email]]
Sent: Monday, March 28, 2011 4:31 PM
To: KRAUS, LAURIE A (ATTCORP); [hidden email]
Subject: RE: Want to modify workflow so RESOLVED isn't a mandatory
transition state for everything

KRAUS, LAURIE A (ATTCORP) wrote:
> In the Bugzilla 3.6.4 Administration, I want to customize the workflow
> to be close to what we are currently use using with our current bug
> tracking process. The RESOLVED state is checked off as being an option
> from all other states and it is grayed out so you can't uncheck it.
>
> What is the reason for this? Is there a way to change this? For
example,
> we have a state called DELIVERED after the bug has been resolved,
which
> is when several bugs are packaged in a build and is delivered to
System
> Test.  RESOVED isn't a valid state to transition to from DELIVERED>

Is resolved set as your status for DUPLICATE?  If so, then you have to
enable it so that a bug can always get to RESOLVED/DUPLICATE.

There should be a note explaining this, and how to fix it, at the bottom
of the workflow chart.  I set my bz to use REJECTED for duplicates, and
here is the text:
When an issue is marked as a duplicate of another one or is moved to
another installation, the issue status is automatically set to REJECTED.
All transitions to this issue status must then be valid (this is the
reason why you cannot edit them above).


_______________________________________________
support-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [hidden email] in the To: field when you reply.
Reply | Threaded
Open this post in threaded view
|

RE: Want to modify workflow so RESOLVED isn't a mandatory transition state for everything

Tosh, Michael J
KRAUS, LAURIE A (ATTCORP) wrote:
> Thanks. I went to the Parameters page and the only choices it gave me
> for duplicates were RESOLVED and CLOSED. But I have been playing with
> the workflow in my sandbox version so I don't know if this impacted my
> choices. What determines what are valid choices? I did look at the
> documentation, but couldn't find anything on this.

I believe that any status that you mark as CLOSED can be used.  I added REJECTED myself using the Field Values administration page.
_______________________________________________
support-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [hidden email] in the To: field when you reply.
Reply | Threaded
Open this post in threaded view
|

RE: Want to modify workflow so RESOLVED isn't a mandatory transition state for everything

KRAUS, LAURIE A (ATTCORP)
OK, I see where you do that. Thanks for your help.


-----Original Message-----
From: Tosh, Michael J [mailto:[hidden email]]
Sent: Monday, March 28, 2011 5:47 PM
To: KRAUS, LAURIE A (ATTCORP); [hidden email]
Subject: RE: Want to modify workflow so RESOLVED isn't a mandatory
transition state for everything

KRAUS, LAURIE A (ATTCORP) wrote:
> Thanks. I went to the Parameters page and the only choices it gave me
> for duplicates were RESOLVED and CLOSED. But I have been playing with
> the workflow in my sandbox version so I don't know if this impacted my
> choices. What determines what are valid choices? I did look at the
> documentation, but couldn't find anything on this.

I believe that any status that you mark as CLOSED can be used.  I added
REJECTED myself using the Field Values administration page.
_______________________________________________
support-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [hidden email] in the To: field when you reply.