Closed
Bug 172772
Opened 22 years ago
Closed 16 years ago
Provide capability for sites with OR groups to merge back to main Bugzilla
Categories
(Bugzilla :: Bugzilla-General, enhancement, P2)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bugreport, Assigned: nobody)
References
Details
Bugzilla currently uses AND-groups (a bug is visible if the user is in ALL of its groups), but some sites use OR-groups. As previously discussed, it is nearly impossible to convert a site. There are several options... 1) Write the queries in CanSeeBug and Search.pm in a way that is effectively parameterized. 2) Remove visibility checks from Search.pm and use CanSeeBug (though I require proof that this will not cause a 10x slowdown) I am leaning toward option 1. Essentially, there would be a place in the query where the word NOT is inserted for OR queries and another place where a NOT is removed. An immediate corrolary question.... If AND groups and OR groups are both in existance, do we make that a Param and support complete installations using OR queries or do we do something like... # use_or_queries, if set to non-zero, makes bug restrictions permit users who # are a member of ANY of the groups instead of ALL of the groups. Do not set # this unless you are proficient with all of the group security implications # you have been warned. $::use_or_queries = 0; For benchmarking potential solutions to this, I suggest the standard test case be a databse with 50000 bugs, 1000 users, and 1000 groups of which 500 are groups that all the users are members and 500 are groups of which most users are not a member. 30 bugs are visible by virtue of being restricted to only 10 of the 500 groups to which all the users belong. The rest are restricted to those 10 groups as well as 10 groups to which none of the users belong. My previous tests have shown a 10x degredation if all the bugs are fetched and then CanSeeBug (using SendSQL) is called for each.
Comment 1•22 years ago
|
||
As I mentioned to joel on IRC, I suspect a large part of that 10x slowdown is because yo're using SendSQL in a tight loop. Try it using the dbi instead, ie: my $sth = $::db->prepare_cached("SELECT..."; my $arr = $::db->fetchrow_arrayref($sth, $bug_id, $user); and then test $arr->[0], and so on.
Reporter | ||
Comment 2•22 years ago
|
||
If we have any evidence of prepare_cached speeding anything up by 10x or more, that experiment is worth a try.
Reporter | ||
Comment 3•22 years ago
|
||
OK... the descision seems to be as follows... AND groups VS OR groups will be either a param or a localconfig option, initially STONGLY encouraged to stay in the AND position. After OR groups are wrung out by the daring few, the default for new installations may change.
Comment 4•22 years ago
|
||
I don't think this is appropriate to allow the administrator to simply change. This can easily and fundamentally change the security settings of an installation. If you have AND groups, I can't imagine a circumstance where you would want to switch to OR groups. If we want to make it easy to use OR-groups, a better solution would be a boolean in the code somewhere.
Comment 5•22 years ago
|
||
I use AND groups now because I'm forced to. If OR groups were available I'd rather use them. Therefore I would switch if I were given the option. Even if it had large security implications, requiring me to go through and resecure all the existing bugs according to the new rules.
Comment 6•22 years ago
|
||
Yeah, this isn't the thing we want to pref. I vote for 'or' groups, too, mainly because they'd make some of the SQL a lot simpler. I'm unsure how we can sensiblyt do the conversion, though, short of creating one group for every possible combination of old groups, and using the inheritance to take care of it. Maybe a checksetup.pl prompt, or something? We do not want to be supporting two schemes.
Reporter | ||
Comment 7•22 years ago
|
||
I think we're going to have to proceed with some care.... 1) provide hooks in the code to permit development and testing of OR groups while continuing to support only AND groups. 2) develop and test the heck out of OR groups 3) consider switching
Reporter | ||
Comment 8•22 years ago
|
||
I'm putting this up for grabs for a new owner.
Assignee: bugreport → nobody
Comment 9•20 years ago
|
||
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 10•20 years ago
|
||
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
Comment 11•19 years ago
|
||
*** Bug 308599 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•19 years ago
|
||
I thing it is reasonable to start adding code to make the installation switchable to OR groups but not officially supporting that mode until 2.24. I suggest that we start a meta-bug with a list of the necessary bugs. I can very easily retrofit the core Search.pm and User::can_see_* functions to be switchable if someone decides to take the lead on the project and decides what we should use to control the mode switch between AND and OR groups. It seems like something that should go into Config.pm to me.
Comment 13•19 years ago
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: bugzilla/2.18.1 I use the bugzilla 2.18.1 and have a productA The Group Access Controls groupA: Default/Default groupB: Default/Default groupC: Default/Default groupD: Default/Default The groupA->user(user1,user2) groupB->user(user3,user4) groupC->user(user5,user6) groupD->user(user7,user8) Reproducible: Always Steps to Reproduce: 1. when user1 new a bug 1,select the groupA,groupB,groupC . Actual Results: 1.the bug 1 only user1 can see. Expected Results: 1.The users of groupA,groupB and groupC can see the bug 1,but the users of groupD can not see the bug. when user1 new a bug 2 ,select the groupA. the result only the groupA can see the bug.It is right. How can I do?
Reporter | ||
Comment 14•19 years ago
|
||
czy: Usage questions belong in the newsgroup
Comment 15•19 years ago
|
||
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
Comment 16•18 years ago
|
||
*** Bug 329540 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 17•18 years ago
|
||
We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.
Target Milestone: Bugzilla 3.0 → ---
Comment 18•16 years ago
|
||
This is WONTFIX in favor of bug 452525, particularly given all the comments in this bug that say that we don't want a pref, we just want to have OR groups.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•