List:Eventum General Discussion« Previous MessageNext Message »
From:M  IN BLR SISL Srivathsan Date:July 8 2009 4:03am
Subject:RE: Eventum Groups
View as plain text  
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 can also tell you that your suggestion was exactly my initial idea.  In any case, let
the debate continue and may the "best" solution be implemented.

Thanks and rgds,

From: Michael Diamond [mailto:dimo414@stripped]
Sent: Wed, 08-Jul-2009 09:19
To: Srivathsan, M IN BLR SISL
Cc: eventum-users@stripped
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.


Michael Diamond

On Tue, Jul 7, 2009 at 8:30 PM, Srivathsan, M IN BLR SISL
<M.Srivathsan@stripped<mailto: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 '' 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
'' 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

I fondly hope that somewhere down the time-line, Eventum incorporates this feature.

Thanks and rgds,

-----Original Message-----
From: Bryan Alsdorf [mailto:bryan@stripped<mailto:bryan@stripped>]
Sent: Mon, 22-Jun-2009 11:51
To: Srivathsan, M IN BLR SISL
Cc: Michael Diamond; Marc Rantanen;
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

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:
To unsubscribe:

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 GroupsMarc Rantanen20 Jun
  • Re: Eventum GroupsMichael Diamond20 Jun
    • RE: Eventum GroupsM  IN BLR SISL Srivathsan21 Jun
      • Re: Eventum GroupsBryan Alsdorf22 Jun
        • RE: Eventum GroupsM  IN BLR SISL Srivathsan8 Jul
          • Re: Eventum GroupsMichael Diamond8 Jul
            • RE: Eventum GroupsDavid Anderson8 Jul
              • RE: Eventum GroupsM  IN BLR SISL Srivathsan8 Jul
            • RE: Eventum GroupsM  IN BLR SISL Srivathsan8 Jul
              • Re: Eventum GroupsBryan Alsdorf8 Jul