Closed Bug 28357 Opened 25 years ago Closed 17 years ago

"My Bugs" query should be more robust

Categories

(Bugzilla :: Query/Bug List, enhancement, P2)

Product:
Bugzilla
Component:
Query/Bug List
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 314757

People

(Reporter: sarnold, Assigned: nobody)

References

Details

Attachments

(1 file)

Trivial patch to put UNCONFIRMED in the default my bugs query.
828 bytes, patch
CodeMachine
: review-
Details | Diff | Splinter Review 
Greetings -- the My Bugs link in the nice yellow box doesn't show Unconfirmed
bugs. I think it should show unconfirmed bugs.

I found it when I learned more information about a bug I submitted .. it
surprised me when I couldn't find it through My Bugs.

hehe. :)

Thanks! :)
QA Contact: matty
The action of the My Bugs link is a preference in tweakparams.  If this is your 
own implementation of Bugzilla you're talking about, you'll need to fix your own 
preferences. :)  checksetup.pl can't just go mucking with your preferences 
because it doesn't know what else you had there.  On the other hand, if you're 
talking about mozilla.org's bugzilla (i.e. here) then Terry needs to fix his own 
:) (which he does, I just checked the "My bugs" link here, and it does indeed 
leave out the UNCONFIRMED bugs).  On the other hand, their may be a reason.  If I 
were a bug owner with tons of bugs, I'd rather not see the unconfirmed ones until 
someone confirms them.  But if I reported a bug that was still unconfirmed, I'd 
certainly want it to show up.  Perhaps it's time to change it to two links (bugs 
I reported, bugs assigned to me).

Ah, sorry for the confusion. I meant the Bugzilla "My Bugs" link located in the
little yellow box, near "reports", "my votes", "edit prefs" and "logout".

I could certainly understand a reluctance to put the unconfirmed bugs into the
list -- so a "bugs i've reported" and a "bugs I own" set of links would likely
be the nicest fix. :)

*** Bug 30632 has been marked as a duplicate of this bug. ***
Just to point out for anyone that's not familiar with it, applying that patch 
only changes the default.  You need to check the Reset button next to the pref 
for that in editparams before it'll take effect.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
*** Bug 33658 has been marked as a duplicate of this bug. ***
[rfe] Perhaps it would be nice to allow the bugzilla footer to be customized
through the bugzilla preferences facility; I am thinking that users could use
checkboxes to declare which reports they wanted to be available on the footer
(from their saved queries).

This way, developers that don't want to see the unconfirmed bugs assigned to
them don't have to see them, and other users that follow their submitted bug
reports can see them quite easily. :)

Maybe it would also be nice to have the footer on the initial bugzilla page
(bugzilla.mozilla.org) -- when I head there, I want a specific bug assigned to
me, usually. :) But that is properly the subject of another bug report, not this
one... :)

Thanks Tara. :)
Severity: trivial → enhancement
This should not be a problem.  If "My Bugs" refers to a reporter's bugs, they
should show UNCONFIRMED.  If "My Bugs" shows an assignee's bugs, they shouldn't.

If it shows both, it should show UNCONFIRMED only for the first set.  Advanced
querying can handle this situation.
There's a conflict of interest here - bug reporters probably want a "My Bugs" 
link which contains _all_ the open bugs they've filed; bug assignees don't want 
UNCONFIRMED ones. At the moment, the assignees are winning.

So either we can make this some sort of pref, or leave it as it is - but a lot 
of people will be a touch annoyed if we change the behaviour, I think.

Gerv
Having the assignees win seems clean enough, if the output from buglist.cgi says
there may be UNCONFIRMED, RESOLVED, VERIFIED and CLOSED bugs too.  (As opposed
to bugreports that look like they've been lost from bugzilla).

Still, would Matthew Tuck's suggestion annoy the assignees?
That is, add
  & bug_status=UNCONFIRMED
but also something like
  & field0-0-0=bug_status & type0-0-0=notequals & value0-0-0=UNCONFIRMED
  & field0-0-1=reporter   & type0-0-1=equals    & value0-0-1=(address)

(Not that it matters for me -- now that I got a RESOLVED bug, I noticed that
I as a reported wanted to see that too, at least for a while.  So I bookmarked
my own search instead.  I have to admit, that solution was not all that hard:-)
OK, going on a combination of sarnold's and Matthew's suggestions, here's what I 
would propose for this:

Make the query string for the My Bugs link be a User Preference instead of a 
global Param, so that each user can set it how they want.  The global Param 
should be used as a default any time a new account is created, but the user could 
edit it to search whatever types of bugs they consider to be theirs.  Since the 
developers should be considered to know what they're doing, and the reporters 
aren't necessarily always considered that...  the benefit of the doubt should be 
given to the reporters, and the developers would need to go edit theirs to remove 
the UNCONFIRMED status from it.

Alternatively, there could be some checkboxes for that in the preferences...

"My Bugs" link searches for bugs 
In these states:    Where I:
[X] UNCONFIRMED     [X] am the Reporter
[X] NEW             [X] am the Owner
[X] ASSIGNED        [X] am the QA Contact
[X] REOPENED        [ ] am on the CC list
[ ] RESOLVED        [ ] am on the voter list
[ ] VERIFIED        [ ] have added a comment
[ ] CLOSED

I feel it should be changed for the convenience of reporters over that of 

assignees, on the theory that assignees are likely to be frequent users 

who know how to customize their user preferences.



Besides the bookmark solution above, note that you can effectively 

customize My Bugs in the footer to do whatever you want, by saving a 

query and naming it My Bugs, and editing your prefs to include the custom 

My Bugs and exclude the real one.  That's what I did, although I called it 

"Kanef's Bugs" so I'd remember it was customized.



To me, the fact that users can customize it once they know Bugzilla well 

enough does not mean that it should be left as is.  It means that My Bugs 

should work the way a \new/ user will expect it work; the convenience of 

advanced, frequent Bugzilla users should not be a factor, since they can 

customize it however they like and forget it.



So what do new users expect?  Bugs recently submitted by new users will 

be in the Unconfirmed state, by definition.  I think most people expect that 

"My Bugs" will show the status of the bugs they just submitted; I know I 

did.  Therefore, I would argue that My Bugs should be changed to include 

Unconfirmed bugs.  Splitting into Bugs I Reported and Bugs Assigned to 

Me would also make sense, but people fixing bugs are likely to able to 

customize Mozilla or use bookmarks.



[Making unrelated changes to bug attributes:  Platform is really All, and I 

rephrased the summary because "UNCONFIRMED -- doesn't show up in 

My Bugs" sounded like the bug itself is unconfirmed.]
OS: Linux → All
Hardware: PC → All
Summary: UNCONFIRMED -- doesn't show up in My Bugs → My Bugs should include "UNCONFIRMED" bugs
I wholeheartedly concur.

I agree that the reporters are more important than the assignees, but like I
said, there does not need to be a tradeoff, and this can be resolved to the
satisfaction of everyone using advanced querying.  There is no need for further
preferences.


*** Bug 39041 has been marked as a duplicate of this bug. ***
And newbie reporters should not be forced to do advanced querying in order to 
find bugs they've reported.  Thus the defaults need to be fixed to favor the 
reporters, and the assignees can be the ones using advanced querying, or change 
their personal preferences to set it back.

This is specifically about the "My Bugs" link, and hence it can't be made any
easier for newbies than it already is, clicking a hyperlink!

They can already customise general queries, and if you want to change the
default query for them, there's bug #31397, which has already been WONTFIXed.
Just to make that crystal clear (in case I didn't), the "My Bugs" link can use
advanced querying without newbies knowing what advanced querying is.
OK, the default "My Bugs" link does not include UNCONFIRMED.  If we're catering 
to the newbies, it needs to.  Whether that's done with some sort of advanced 
querying behind the scenes or what, it doesn't matter, but it still needs to 
work with UNCONFIRMED if the person is a reporter.
The problem isn't whether or not "My bugs" include UNCONFIRMED,
but that "My bugs" doesn't do what it says.

* If the result page said that there may be UNCONFIRMED
  (and CLOSED and... other) bugs as well, all would be fine.
  Newbies who want UNCONFIRMED bugs would thus be told that
  "My bugs" isn't for them.

* If the link was called "My active bugs" or something, that
  too would tell newbies that something is going on.

* If UNCONFIRMED bugs from the specified e-mail address were
  included, that too would fix the problem.
Whiteboard: 2.14
Whiteboard: 2.14 → 2.16
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16
*** Bug 74776 has been marked as a duplicate of this bug. ***
matty's suggestion from my report: Or we could split into My Assigned Bugs, My 
QA Bugs and My Reported Bugs.

reported bugs is
&reporter=$me
qa bugs is
&qa_contact=$me&bug_status=NEW&bug_status=RESOLVED
w/ bonus points for an alternative query, 
&qa_contact=$me&keywords=qawanted+verifyme&keywords_type=anywords
assigned bugs is
&assigned_to=$me&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
for bonus points:
We could set the default to only show My Reported bugs. If a person is given a 
default QA position then we should automatically enable My QA Bugs (if they've 
never changed the setting).  If a person has not toggled my Assigned Bugs then 
we should show the field if they have assigned bugs.

for status quo, we'd just show My Assigned and My Reported.
Timeless says it's my turn to add comments, so...:

I like the queries and ideas in Timeless's post, though I think that 
unconfirmed should be addded to the 'my qa' link. As a qa contact, I would 
find this extremely useful. Also, GET RID OF THE DANG 'MY'! What will this 
lead to? Compulsive my'ing. Myk has already started using the nick 'my-k' 
to make sure that everyone know who owns him. Who knows what will 
come next!
ok, after some conversation, we have the following changes

My Assigned Bugs=>Assigned
My QA Bugs=>QA
My Reported Bugs=>Reported
this is actually semi consistent w/ the language i used later to describe these 
queries.

QA should also query for UNCONFIRMED, suggested by zach and seconded by me.

Sorting default site params:
QA by bug_status
Reported by resolution
Assigned by target milestone
looks good
We need to consider:

(a)  What to do with the existing system parameter.  Do we need it anymore?  Do
we want to make three parameters?
(b)  What to do with existing users.  I suggest that if we do the following in
checksetup.pl:

If they have it off, leave all three off.
If they have it on,
	turn on Reported Bugs if they have reported bugs, QA Bugs if they are a QA
contact for a component or bug, etc.
	turn on Reported Bugs if they have done none of these.

(c)  What to do with new users.  At user add, we could ask what to turn on,
either with three checkboxes, or we could ask the primary function of this
account and turn that one on.  Or we could just assume they're a reporter and
expect the others to fix themselves up.
Priority: P3 → P2
Whiteboard: 2.16
Keywords: patch, review
->New product Bugzilla.
Assignee: tara → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → unspecified
Comment on attachment 6680 [details] [diff] [review]
Trivial patch to put UNCONFIRMED in the default my bugs query.

Marking this patch needs work, as we want a more extensive solution.
Attachment #6680 - Flags: review-
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
See bug 69000 - something along those lines would probably work.
Resummarizing per comment 30.
Summary: My Bugs should include "UNCONFIRMED" bugs → "My Bugs" query should be more robust
Keywords: review
Another option would be to add a set of queries by default for each new user to
the stored queries table. I'm against having "special" queries like My Bugs;
they are a pain. Bug 69000 would work too, of course.

Gerv
*** Bug 177963 has been marked as a duplicate of this bug. ***
*** Bug 220382 has been marked as a duplicate of this bug. ***
*** Bug 223268 has been marked as a duplicate of this bug. ***
Assignee: endico → nobody
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
*** Bug 249365 has been marked as a duplicate of this bug. ***
*** Bug 129176 has been marked as a duplicate of this bug. ***
*** Bug 254682 has been marked as a duplicate of this bug. ***
*** Bug 259379 has been marked as a duplicate of this bug. ***
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
*** Bug 262944 has been marked as a duplicate of this bug. ***
*** Bug 281911 has been marked as a duplicate of this bug. ***
Depends on: 314757
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---
This bug has been around a while, but it looks as if "My Bugs" DOES show Unconfirmed bugs for bug reporters now.  Are there other portions of this bug that are keeping its status from being resolved?
(In reply to comment #47)
> This bug has been around a while, but it looks as if "My Bugs" DOES show
> Unconfirmed bugs for bug reporters now.

Yes, this has been fixed by bug 314757. So for me personally, the main point of this bug here has been fixed.

> Are there other portions of this bug that are keeping its status from being
> resolved?

Still open as per (at least) comment 12 and comment 24...
QA Contact: mattyt-bugzilla → default-qa
In my experience working with users, the problem with My Bugs is not that UNCONFIRMED bugs are missing (we aren't using that state), but that RESOLVED bugs are missing.  In our workflow, reporters report bugs, developers fix them, and bug reporters close them.  In this workflow, the "My Bugs" query should show:
 (status = (NEW or ASSIGNED)) and (assigned-to = $me)
 OR
 (status = RESOLVED) and (reporter = $me)

I have tried to customize the default query string in 2.22 to reflect this but haven't yet been able to decipher the boolean charts and URL query syntax to get it to work.  Any help would be welcome, and I would consider this workflow well-supported if there was simply documentation on how admins can change the default My Bugs to work this way.
well I'd like to know how to add all the bugs I've asked to be copied into, as well as obviously remove them, when time doesn't allow...
The original stuff suggested in this bug was handled by bug 314757.

The other stuff can be handled by bug 133173 or by making "My Bugs" into its own special page (which is more likely to happen).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: