From: Bryan Alsdorf
Date: July 8 2009 4:43am
Subject: Re: Eventum Groups
List-Archive: http://lists.mysql.com/eventum-users/5598
Message-Id: <4A542402.50900@askmonty.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Watson,

Thanks for taking lead on this!

Srivathsan, M IN BLR SISL wrote:
> Hi Michael,
> 
> I completely agree with you on the 'id' column - it was my mistake; got really psyched seeing very many 'id' columns in many of the Eventum tables.
> 
> Regarding your suggestion on the Primary Group funda, I largely agree with that.  But I felt that providing Backward Compatibility - not just in the code but all for all the deployed Eventum-based solutions, is far more important.  The changes we are doing should be a kind of a "drop-in" patch in all such deployments that would not affect their current functionality.  Whether that is really possible or not is another question and I have not gone deeper to analyze that.

I am a big fan of backward compatibility as well but in this case I would like to go for 
the simpler, non-backwards compatible solution. We have been making some other large 
changes to Eventum for a 3.0 release (and many more changes yet to come) so now is the 
time to break backwards compatability for groups. Also because groups are so limited now I 
don't think many people are using them. If people do want to continue to use only one 
group per user it will be an extremely trivial change to their backends.

More comments below.

> 1. In order to provide for multiple Group membership for Users, there needs to be a new table created, like "user_group_association".  This table could have 3 cols - 'id', 'usr_id' and 'grp_id'

Lets just call it user_group and please prefix all columns with ugr_ and I agree witht he 
comment we don't need an id column, ugr_usr_id and ugr_grp_id will form the primary key.
> 
> 2. Apart from 'class.group.php' which needs to be accordingly revamped, there are 3 functions in 'class.user.php' that are impacted:
>    - getGroupID($usr_id)
>    - setGroupID($usr_id)

These should be renamed to getGroupIDs/setGroupIDs.

>    - getActiveAssocList(..., $exclude_grouped, $grp_id)

Should be an easy change, $exclude_grouped will stay exactly the way it is and $grp_id 
will just check if user_group to see if the user is a part of the group.

> 
> 3. We could very well retain the above 3 methods 'as is' if we go in for "Primary Group" and "Secondary Group" concept.  Whatever that is there in the 'user' table would be the Primary Group of the User.  All additional groups would be Secondary Groups and will be stored in the 'user_group_association' table.
> 
> 4. By this, I believe that we could restrict all the "additional" modifications within 'class.group.php' itself.  Also, the existing code that depends on the 3 methods mentioned in point #2 need not be touched.
> 
> 5. From my experience, multiple group membership based logic is mainly required in the backend engines we code and attach to Eventum.  Hence we could have the feature without breaking the existing functionalities

There isn't a lot of code that calls those 3 functions, should be relatively easy to 
refactor them.

> 
> 6. Ofcourse, "Manage Groups" page and related functionalities should change to accommodate multiple Group membership.
> 
> I am sure that there would be 'gotchas' in my suggestion above.  Hence I humbly solicit Expert Review Comments on the above points.  Even totally different alternatives are most welcome.
> 
> I fondly hope that somewhere down the time-line, Eventum incorporates this feature.

Great proposal, I would love to see a tree on launchpad with this feature that I can merge 
into the main branch.

/bryan