891311 - Text in the "My Requests" page is misleading about how the AND/OR radio button works

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, defect)

Description

[Frédéric Buclin]

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

[Frédéric Buclin]

Attachment: patch, v1

Comment 2

[:glob ✱]

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

[Frédéric Buclin]

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

[Frédéric Buclin]

justdave, see my previous comment.

Comment 5

[Dave Miller [:justdave]]

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

[Frédéric Buclin]

Attachment: patch, v2

Comment 7

[David Lawrence [:dkl]]

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

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified request.cgi
modified template/en/default/request/queue.html.tmpl
Committed revision 8766.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.4/
modified request.cgi
modified template/en/default/request/queue.html.tmpl
Committed revision 8616.