A Couple of Bugzilla Issues

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

A Couple of Bugzilla Issues

Jesse Bonnell
Hey guys,

My first issue is: let's say a bug is created as NEW, and is then
assigned/accepted so it gets put into the ASSIGNED state. If the bug gets
reassigned to someone else, then it goes back to NEW. This can be kind of
confusing - is there any way to prevent it from doing this and have it
remain as ASSIGNED?

My second issue is: you have the list of bugs from the search results. You
go to edit one of the bugs, and upon hitting 'Commit,' it takes you to the
next bug in the list. Is there a way so that when you submit the changes to
that bug, it keeps you on the same bug rather than moving to the next bug?

Thanks.


J


_______________________________________________
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: A Couple of Bugzilla Issues

Torsten Martinsen
Jesse Bonnel wrote:

> My second issue is: you have the list of bugs from the search
> results. You go to edit one of the bugs, and upon hitting 'Commit,' it
> takes you to the
> next bug in the list. Is there a way so that when you submit
> the changes to
> that bug, it keeps you on the same bug rather than moving to
> the next bug?

Default Preferences -> After changing a bug -> Show the updated bug

-Torsten
_______________________________________________
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: A Couple of Bugzilla Issues

Marc Schumann
In reply to this post by Jesse Bonnell
Jesse,

2006/8/23, Jesse Bonnell <[hidden email]>:
> My first issue is: let's say a bug is created as NEW, and is then
> assigned/accepted so it gets put into the ASSIGNED state. If the bug gets
> reassigned to someone else, then it goes back to NEW. This can be kind of
> confusing - is there any way to prevent it from doing this and have it
> remain as ASSIGNED?

it's actually a good thing that it goes back to NEW because setting to
ASSIGNED is an active acknowledgement. NEW means to the current
assignee: "I need to look at it and decide whether I set it to
ASSIGNED or reassign it to somebody else". A person getting a bug
needs to decide this anew.

To answer your question: without modification, this is not possible.

> My second issue is: you have the list of bugs from the search results. You
> go to edit one of the bugs, and upon hitting 'Commit,' it takes you to the
> next bug in the list. Is there a way so that when you submit the changes to
> that bug, it keeps you on the same bug rather than moving to the next bug?

At Prefs > General Preferences, set the "After changing a bug" setting
to "Show the updated bug". This is possible since 2.20 or 2.22, I
think.

Keep in mind that you should take care to bundle all your changes into
a single hit on Commit, because every Commit hit will send e-mail to
people related to the bug. So for the sake of your co-workers, please
don't abuse this functionality and do separate Commits for each change
:)

   Kind regards
      Marc
_______________________________________________
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: A Couple of Bugzilla Issues

Jesse Bonnell
In reply to this post by Jesse Bonnell
Thanks guys. We're still running 2.20.2, and I don't think we have the
option in Preferences to change that - so this might be a matter of
upgrading. As for my first issue though, let me kind of explain the
situation we have at my company:

Every week a team gets together and they have these "triage meetings" to
discuss mainly the bugs in Bugzilla (and elsewhere too, but we're moving
towards just Bugzilla). So an idea we had was if there was some way when a
bug was created - a checkbox, saying "needs triage" or something along those
lines, is by default already checked. So then they could query all the Bugs
with those boxes checked, and then bring those up in the meeting. After
this, they are unchecked so they know they have already been discussed.

That's mainly the issue with the NEW and ASSIGNED thing, because they just
want some way to query new bugs and knows which bugs have been triaged.

Has anyone or their company, facing a similar situation, found a way to do
this most effectively using Bugzilla?



"Marc Schumann" <[hidden email]> wrote in message
news:[hidden email]...

> Jesse,
>
> 2006/8/23, Jesse Bonnell <[hidden email]>:
>> My first issue is: let's say a bug is created as NEW, and is then
>> assigned/accepted so it gets put into the ASSIGNED state. If the bug gets
>> reassigned to someone else, then it goes back to NEW. This can be kind of
>> confusing - is there any way to prevent it from doing this and have it
>> remain as ASSIGNED?
>
> it's actually a good thing that it goes back to NEW because setting to
> ASSIGNED is an active acknowledgement. NEW means to the current
> assignee: "I need to look at it and decide whether I set it to
> ASSIGNED or reassign it to somebody else". A person getting a bug
> needs to decide this anew.
>
> To answer your question: without modification, this is not possible.
>
>> My second issue is: you have the list of bugs from the search results.
>> You
>> go to edit one of the bugs, and upon hitting 'Commit,' it takes you to
>> the
>> next bug in the list. Is there a way so that when you submit the changes
>> to
>> that bug, it keeps you on the same bug rather than moving to the next
>> bug?
>
> At Prefs > General Preferences, set the "After changing a bug" setting
> to "Show the updated bug". This is possible since 2.20 or 2.22, I
> think.
>
> Keep in mind that you should take care to bundle all your changes into
> a single hit on Commit, because every Commit hit will send e-mail to
> people related to the bug. So for the sake of your co-workers, please
> don't abuse this functionality and do separate Commits for each change
> :)
>
>   Kind regards
>      Marc


_______________________________________________
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: A Couple of Bugzilla Issues

Mike Finn
Jesse Bonnell wrote:

> Thanks guys. We're still running 2.20.2, and I don't think we have the
> option in Preferences to change that - so this might be a matter of
> upgrading. As for my first issue though, let me kind of explain the
> situation we have at my company:
>
> Every week a team gets together and they have these "triage meetings" to
> discuss mainly the bugs in Bugzilla (and elsewhere too, but we're moving
> towards just Bugzilla). So an idea we had was if there was some way when a
> bug was created - a checkbox, saying "needs triage" or something along those
> lines, is by default already checked. So then they could query all the Bugs
> with those boxes checked, and then bring those up in the meeting. After
> this, they are unchecked so they know they have already been discussed.
>
> That's mainly the issue with the NEW and ASSIGNED thing, because they just
> want some way to query new bugs and knows which bugs have been triaged.
>
> Has anyone or their company, facing a similar situation, found a way to do
> this most effectively using Bugzilla?
>
>
>

We have co-opted another field that we would otherwise not use (OP_SYS
in our case). We've renamed it 'TRIAGED' with possible values 'NO' and
'YES' with the default 'NO'. During the triage meeting as we go over
each defect, we mark it yes (and usually assign it to someone).

Making a saved search for TRIAGED=NO is, of course, simple.
_______________________________________________
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: A Couple of Bugzilla Issues

Michael Bellomo
An other option would be to hijack the status whiteboard field if you're
not using that.

Or you could just use a flag...that's sorta what flags are for, boolean
things.  Make a flag named triage.  Then you could set them to '?' to
decide if they're a problem, '+' or '-' after you decide it is or isn't
a problem.  And you could find them easily enough with searches.

    -Michael

Mike Finn wrote:

> Jesse Bonnell wrote:
>> Thanks guys. We're still running 2.20.2, and I don't think we have
>> the option in Preferences to change that - so this might be a matter
>> of upgrading. As for my first issue though, let me kind of explain
>> the situation we have at my company:
>>
>> Every week a team gets together and they have these "triage meetings"
>> to discuss mainly the bugs in Bugzilla (and elsewhere too, but we're
>> moving towards just Bugzilla). So an idea we had was if there was
>> some way when a bug was created - a checkbox, saying "needs triage"
>> or something along those lines, is by default already checked. So
>> then they could query all the Bugs with those boxes checked, and then
>> bring those up in the meeting. After this, they are unchecked so they
>> know they have already been discussed.
>>
>> That's mainly the issue with the NEW and ASSIGNED thing, because they
>> just want some way to query new bugs and knows which bugs have been
>> triaged.
>>
>> Has anyone or their company, facing a similar situation, found a way
>> to do this most effectively using Bugzilla?
>>
>>
>>
>
> We have co-opted another field that we would otherwise not use (OP_SYS
> in our case). We've renamed it 'TRIAGED' with possible values 'NO' and
> 'YES' with the default 'NO'. During the triage meeting as we go over
> each defect, we mark it yes (and usually assign it to someone).
>
> Making a saved search for TRIAGED=NO is, of course, simple.
> _______________________________________________
> support-bugzilla mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/support-bugzilla
> PLEASE put [hidden email] in the To: field when
> you reply.
> .
>
_______________________________________________
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: A Couple of Bugzilla Issues

Marc Schumann
In reply to this post by Jesse Bonnell
Jesse,

2006/8/23, Jesse Bonnell <[hidden email]>:
> towards just Bugzilla). So an idea we had was if there was some way when a
> bug was created - a checkbox, saying "needs triage" or something along those
> lines, is by default already checked. So then they could query all the Bugs

you'd typically use the UNCONFIRMED state for this.

   Regards
      Marc
_______________________________________________
support-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [hidden email] in the To: field when you reply.