List:Eventum General Discussion« Previous MessageNext Message »
From:Michael Diamond Date:July 8 2009 3:49am
Subject:Re: Eventum Groups
View as plain text  
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> 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 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:
> To unsubscribe:

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