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
> 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.