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)

2.17
enhancement

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.
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.
If we have any evidence of prepare_cached speeding anything up by 10x or more,
that experiment is worth a try.

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.

Assignee: justdave → bugreport
Depends on: 114696, 147275
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18
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.
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.
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.

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
Blocks: bz-zippy
I'm putting this up for grabs for a new owner.
Assignee: bugreport → nobody
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
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
*** Bug 308599 has been marked as a duplicate of this bug. ***
Blocks: 278781
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.
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?
czy: Usage questions belong in the newsgroup
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
*** Bug 329540 has been marked as a duplicate of this bug. ***
QA Contact: mattyt-bugzilla → default-qa
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 → ---
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.