Last Comment Bug 891311 - Text in the "My Requests" page is misleading about how the AND/OR radio button works
: Text in the "My Requests" page is misleading about how the AND/OR radio butto...
Product: Bugzilla
Classification: Server Software
Component: Attachments & Requests (show other bugs)
: 4.4
: All All
-- normal (vote)
: Bugzilla 4.4
Assigned To: Frédéric Buclin
: default-qa
Depends on: 206455
  Show dependency treegraph
Reported: 2013-07-09 04:32 PDT by Frédéric Buclin
Modified: 2013-09-28 04:34 PDT (History)
3 users (show)
justdave: approval+
justdave: approval4.4+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

patch, v1 (705 bytes, patch)
2013-07-09 04:34 PDT, Frédéric Buclin
glob: review-
Details | Diff | Splinter Review
patch, v2 (5.59 KB, patch)
2013-08-14 09:04 PDT, Frédéric Buclin
dkl: review+
Details | Diff | Splinter Review

Description User image Frédéric Buclin 2013-07-09 04:32:32 PDT
In the "My Requests" page, the description of the AND/OR radio button says:

"The logical conjunction/disjunction between the requester and the requestee"

But in fact, the radio button applies to all fields, not the requester vs requestee fields only. So if you set requester = foo, requestee = bar, product = baz with OR, you get:

requester = foo OR requestee = bar OR product = baz

instead of

(requester = foo OR requestee = bar) AND product = baz

The current behavior is the expected one, as it has been implemented this way in Bugzilla 2.18, see bug 179881. So what's wrong is the description of the radio button which should make clear that it affects all fields.
Comment 1 User image Frédéric Buclin 2013-07-09 04:34:56 PDT
Created attachment 772607 [details] [diff] [review]
patch, v1
Comment 2 User image Byron Jones ‹:glob› 2013-07-29 07:42:37 PDT
Comment on attachment 772607 [details] [diff] [review]
patch, v1

i've always thought that ui was clumsy; if we're going to change it, let's fix up the wording or make it self-descriptive.

i think it would be clearer to have a <select> instead of a <radio>, with the two options being something like "Show requests matching ALL set fields" and "Show requests matching ANY set fields" (i'm not particularly attached to this wording).

the behaviour of OR isn't a "logical conjunction between fields" as this implies all fields are OR'd.  if you have the requster and requestee set, with all other fields set to any, the results are limited to just "requester OR requestee".

perhaps instead of using Any/all as the default value for the selects, it should be "-" or similar to indicate that field isn't being used as part of the query.
Comment 3 User image Frédéric Buclin 2013-07-30 11:03:07 PDT
To be honest, the way OR works is really counter-intuitive. I want to track all review requests related to me in the Bugzilla product, so I select product = Bugzilla, flag = review, requester = requestee = LpSolit, and the list I get is totally useless, because everything is OR'ed. IMO, OR only makes sense for the requester vs requestee field. Any objection to change the way it currently works? As there was no UI for AND/OR in the past, I doubt this change affects a lot of people.
Comment 4 User image Frédéric Buclin 2013-08-09 01:50:07 PDT
justdave, see my previous comment.
Comment 5 User image Dave Miller [:justdave] ( 2013-08-09 02:00:30 PDT
hmmm...  the usecase for that is sort of fulfilled by the dashboard page these days (although that's a bmo extension and not part of core).

In any case, I kinda like the dropdown idea, because that makes it match the UI used for that concept in the custom search section of the search page.

It also seems like only applying it to the requestor and requestee and making everything else be AND anyway would fit the vast majority of the use-cases on there. If we really want to allow ORing those other fields then we need a more-involved UI I think
Comment 6 User image Frédéric Buclin 2013-08-14 09:04:14 PDT
Created attachment 790257 [details] [diff] [review]
patch, v2
Comment 7 User image David Lawrence [:dkl] 2013-09-27 09:55:46 PDT
Comment on attachment 790257 [details] [diff] [review]
patch, v2

Review of attachment 790257 [details] [diff] [review]:

Looks good and works as expected. r=dkl
Comment 8 User image Frédéric Buclin 2013-09-28 04:34:24 PDT
Committing to: bzr+ssh://
modified request.cgi
modified template/en/default/request/queue.html.tmpl
Committed revision 8766.

Committing to: bzr+ssh://
modified request.cgi
modified template/en/default/request/queue.html.tmpl
Committed revision 8616.

Note You need to log in before you can comment on or make changes to this bug.