Closed Bug 184081 Opened 22 years ago Closed 22 years ago

Change search interfaces to use Viewable products instead of enterable products

Categories

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

2.17.1
Other
Other
enhancement

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: bugreport, Assigned: bugreport)

Details

Attachments

(1 file)

Currently, a user who cannot enter a bug into a product cannot narrow a search
for bugs or requests to that product even if he can see bugs.  This is because
those interfaces use enterable products as the criteria.

These interfaces should use a list of searchable products that is a superset of
their enterable products.  This can be implemented in one of several ways....

1) Now that we have a CANEDIT restriction for products, we could view the
definition as ... a product is searchable if the user has entry but cannot
actually be entered if the user fails to meet any CANEDIT restrictions. 
(Currently to would be very strange to give someone entry while blocking him
with a canedit restriction.... this would become a way to indicate that the user
can search but not really enter)

OR

2) In addition to the enterable products, we could add any products to the
search list for which there is a Mandatory group AND the user satisfies it.

I am leaning toward option 2.
I'll wait a day for comment before starting implementation.  I'm marking this a
P1 because it is rather critical for common enterprise groups usage scenarios.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.18
Seems to me this used enterable on purpose because the original vision of the
enterable vs. viewable concept was that you might be able to enter bugs into
more products than you can view (thanks to the magic of reporter_accessible and
leaving "usebuggroupsentry" turned off), and then you'd never be able to search
for bugs you had entered.  Maybe it needs to have some sort of union of the two
lists of products.
The idea is that you shouldnt' be able to search for anything which you don't
know exists ('knowing' by being ccd to a bug with cclist_Accessible doesn't
count, but theres nothing stopping someone from using the boolean chart stuff in
that case)

For (2), don't you mean _all_ mandatory groups. Why can't you use the same code
you used for the requests popup?
  I think we're covered with approach #2.  In addition to any products the user
can enter, he should be able to search on any products to which other users are
categorically excluded but he is not.

  No matter what, the search results will only show what the user is authorized
to see.

  Originally, if I was not part of the entry group, I would not be able to see
the product even though I might be able to see many of the bugs for the product.
 That is silly.

  The problem is that both the request searches and the queries will only allow
the user to narrow the search to products to which the user could WRITE.  That
seems silly and, in particular, if I have read-only access to product A and
product B as well as read/write to product C, I am currently unable to search
for only those bugs in Product A.  I can either serach for bugs in product C or
else leave the search unconstrained and get A, B, and C.

  If a product is supposed to be completely invisible to me and is using
mandatory groups, I will only see bugs in the product if I satisfy those
mandatory groups.  It seems that I should then be able to see that the product
exists.  If a site is taking advantage of the ability to have mandatory groups,
they can very easily keep me from knowing a product exists by assigning a
mandatory group to which I do not belong.  Leaving the decision to expose a bug
to me to anyone who can edit that bug is certainly not something that a site
would do if they don't want me to know that the product exists.
Sure, that makes sense, but GetEnterableProducts doesn't care about canedit, so
I'm not really sure what you're asking to change.

Your last two paragraphs are confusing me; perhaps I need to see some code, or
talk on irc, or something
I'll try one more whack at this and then we'll have to discuss it on IRC.  I
haven't been very inclined to be nocturnal lately.

The old behavior uses enterable products for searching.  There was no concept in
those days of a reliably invisible product because there was no such thing as a
mandatory group restriction.

Now, it is possible (and important) to have products that a user can be
permitted to see but which are not enterable by that user.  A user should be
permitted to search those specifically.  For this reason, using the entry
restrictions is the wrong thing to do except for backward compatibility with
sites using usebuggroupsentry.

So, the right thing is to 
1) have 2 distinct functions.  One gets Enterable products and the other gets
selectable products and use the appropriate function in the appropriate place.
2) Enterable should stay exactly as it is today.  
3) Selectable should vary based on the setting of useentrygroupdefault (formerly
usebuggroupsentry).  If useentrygroupdefault is true, Selectable should just
defer to enterable.  If not, Selectable should make any product where the user
satisfied the mandatory group requirements visible.

Attachment #108663 - Flags: review?(bbaetz)
Comment on attachment 108663 [details] [diff] [review]
Selectable Products patch

r=bbaetz, I guess. I'm not sure that its the best ui, but it sbetter than what
we have.
Attachment #108663 - Flags: review?(bbaetz) → review+
Flags: approval?
Flags: approval? → approval+
checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: