Groups Architecture

[Joel Peshkin]

Max Kanat-Alexander wrote:
> 	There's been a lot of discussion in bug 240086, and Gerv rightfully
> pointed out that we should take it to the mailing list.
>
> 	Here's a link to the bug:
>
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=240086
>
> 	And here's a link to my latest comment on the bug, which is where I
> proposed a sort of re-architecture of the groups system instead of what
> the current patch does:
>
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=240086#c69
>
> 	So, discuss? :-)
>
> 	-Max
>   

It would actually not be immensely hard to make the code able to be 
configured for AND groups or OR groups, but it would be extremely hard 
to automate migration.  First of all, I believe that the only place 
where there is "more than one lock" on a door is in bug visibility. All 
of the other places I can think of are single locks where AND groups are 
equivalent to OR groups.

The current check for visibility is done by joining a bug list with....
LEFT JOIN bug_group_map
    ON bug_group_map.bug_id = bugs.id
        AND bug_group_map.group_id NOT IN( $list_of_groups_you_are_in)
    WHERE bug_group_map.group_id IS NULL

If we want to invert that, we make it....

LEFT JOIN bug_group_map
    ON bug_group_map.bug_id = bugs.id
        AND bug_group_map.group_id  IN( $list_of_groups_you_are_in)
    WHERE bug_group_map.group_id IS NOT NULL

[and we can either let the database optimize it or drop the where clause 
and the "left"]

This search logic **should** only exist in CanSeeBug and in Search.pm.  

Migrating sites from one system to another is a bit harder.  If you have 
3 locks on a door, you have to issue new keys to people that had every 
one of the 7 possible combinations of keys to the door and you have to 
replace the 3 locks with 7 locks.