My two cents would be to try to avoid the 'primary group' idea. Though it
may be more coding (or maybe not - I wouldn't be surprised if a primary
group structure actually made things harder) I think it will be a lot more
logical a shift if the group column is completely removed from the user and
all group operations lookup against the user_group table. This would mean
getGroupID() returns an array (and preferably is renamed getGroupIDs() or
something similar). setGroupID() would give way to addGroupID() and
removeGroupID() and while I don't know what getActiveAssocList() it
similarly would be revamped to handle multiple groups per person.
Additionally, I'm not sure why you need an id column for the many-to-many
user_group table. Simply creating a unique index on the two columns should
be enough - I think. If there's a good reason I'm wrong, feel free to
correct me, but in the past I haven't needed an id for many-to-many tables.
Michael
Michael Diamond
dimo414@stripped
mdiamond@stripped
http://www.DigitalGemstones.com
On Tue, Jul 7, 2009 at 8:30 PM, Srivathsan, M IN BLR SISL <
M.Srivathsan@stripped> wrote:
> Hi all,
>
> I just started the "Step #0" (Step ZERO) of reading the existing code
> pertaining to Eventum User Groups. The following are my understanding /
> observations / recommendations:
>
> 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'
>
> 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)
> - getActiveAssocList(..., $exclude_grouped, $grp_id)
>
> 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
>
> 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.
>
> Thanks and rgds,
> Watson
>
> -----Original Message-----
> From: Bryan Alsdorf [mailto:bryan@stripped]
> Sent: Mon, 22-Jun-2009 11:51
> To: Srivathsan, M IN BLR SISL
> Cc: Michael Diamond; Marc Rantanen; eventum-users@stripped
> Subject: Re: Eventum Groups
>
> Hi,
>
> Srivathsan, M IN BLR SISL wrote:
> > Hi,
> >
> > Sadly for me, Eventum Group funda has been designed to be exclusive. If
> only this was not the case, i.e., if an Eventum User could be a member of
> more than 1 (Eventum) group, it would be have made many of my solutions
> easier.
>
> Unfortunately when I implemented groups I was doing it in a hurry to reach
> a certain goal
> and didn't anticipate the need for multiple groups. It is something I would
> like to see
> fixed, but I don't know when I will get around to it.
>
> I welcome any patches that change this, and would be happy to be involved
> in the design
> process.
>
> Best Regards,
> /bryan
>
> Important notice: This e-mail and any attachment there to contains
> corporate proprietary information. If you have received it by mistake,
> please notify us immediately by reply e-mail and delete this e-mail and its
> attachments from your system.
> Thank You.
>
> --
> Eventum Users Mailing List
> For list archives: http://lists.mysql.com/eventum-users
> To unsubscribe:
> http://lists.mysql.com/eventum-users?unsub=1
>
>
