I would agree in that Groups should just be a many-to-many relationship
with user and that having a primary group would just add unnecessary
Obviously the functions handling groups would have to return arrays
however we also need to consider the functions calling the group
functions also have to be able to handle the returned arrays. It is not
just 'backend engines' that use group - the main issue listing screen
has a filter by group which will need careful changes made to ensure
that screen still works correctly.
I would say that assignment of an issue should still be to the one group
rather than to many.
From: Michael Diamond [mailto:dimo414@stripped]
Sent: Wednesday, 8 July 2009 3:49 p.m.
To: Srivathsan, M IN BLR SISL
Subject: Re: Eventum Groups
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.
On Tue, Jul 7, 2009 at 8:30 PM, Srivathsan, M IN BLR SISL <
> 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
> 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
> 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,
> -----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
> 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,
> 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: