Closed
Bug 184081
Opened 21 years ago
Closed 21 years ago
Change search interfaces to use Viewable products instead of enterable products
Categories
(Bugzilla :: Query/Bug List, enhancement, P1)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: bugreport, Assigned: bugreport)
Details
Attachments
(1 file)
5.47 KB,
patch
|
bbaetz
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•21 years ago
|
||
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
Comment 2•21 years ago
|
||
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.
Comment 3•21 years ago
|
||
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?
Assignee | ||
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
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
Assignee | ||
Comment 6•21 years ago
|
||
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.
Assignee | ||
Comment 7•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #108663 -
Flags: review?(bbaetz)
Comment 8•21 years ago
|
||
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+
Assignee | ||
Updated•21 years ago
|
Flags: approval?
Updated•21 years ago
|
Flags: approval? → approval+
Assignee | ||
Comment 9•21 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•