--
Levi Rosol
Twitter: @LeviRosol
Ok, that makes sense. If I'm understanding you correctly, you're basically talking about Single Table Inheritance (http://wiki.rubyonrails.org/rails/pages/singletableinheritance).
So then to define some sort of ownership of a group, you'd simply add some sort of FK to the User model, like Manager_User_Id ? I suppose though, in my case though, I'd have a cross ref table because we will need the ability to have more than one manager for a group, and a single user could manage more than one group.
has_many :groups, :through => :user_group
But then what about a role based system? ie: manager, moderator, etc I'd want to keep that functionality separate from the current user/role setup because a single user may manage multiple groups.
Hey guys, just wanted to weigh in:
I'm not a fan of implementing Groups by doing inheritance/user_type on the User model, since they're essentially different objects, IMO. So I doubt this kind of implementation would be accepted back into CE (if submitted). I'd much prefer a new Group model with its own logic and views.
In fact, I'd suggest doing this as a CE plugin (basically, a plugin that relies on Engines and CE, implementing groups functionality). The plugin could have its own migrations, models, controllers and views, and just come with the requirement that you have CE installed as well. That way we can work out the kinks and then hopefully integrate it into the core.
Thanks, and good luck.
Bruno
On Wed, Nov 19, 2008 at 10:58 PM, sachin kale <brigh...@gmail.com> wrote:
On Thu, Nov 20, 2008 at 10:11 AM, Levi Rosol <levi....@gmail.com> wrote:Ok, that makes sense. If I'm understanding you correctly, you're basically talking about Single Table Inheritance (http://wiki.rubyonrails.org/rails/pages/singletableinheritance).
I haven't read that and really don't know what it means.
So then to define some sort of ownership of a group, you'd simply add some sort of FK to the User model, like Manager_User_Id ? I suppose though, in my case though, I'd have a cross ref table because we will need the ability to have more than one manager for a group, and a single user could manage more than one group.
has_many :groups, :through => :user_group
But then what about a role based system? ie: manager, moderator, etc I'd want to keep that functionality separate from the current user/role setup because a single user may manage multiple groups.
You can keep group-moderatorship as different model , similar to forum moderatorship, which addresses requirement of user managing multiple groups. This separates it from group-membership.
I haven't done this, as my groups requirement did not had user-created/moderated groups but they were fixed groups having only user- memberships.
Sorry, I'm rambling on here. Clearly I need to spend some more time defining the functionality I need before moving forward. :-)
--
Sachin Kale
That makes sense,
That would be a good addition to CE.
Also going further if it makes sense and is viable, I think we can have all the functionality attached to profile object like - photos/forums/blogs/friendship etc
For group, we can select forum/photos/(membership - friendship model - renamed in the view) etc
For user - photos/comments/blog/friendship etc.
The functionality selection for group/user can be decided from a config file. I am aware this would be huge task though but this would result in more flexibility.
On Fri, Nov 21, 2008 at 10:09 AM, Bruno Bornsztein <bruno.bo...@gmail.com> wrote:
Maybe what you want is a Profile object, a User object, and a Group object. Profile would contain the stuff shared by both, so a User and a Group would both have a profile, but a Group wouldn't have a birthday, like a user would.
Make sense?
On Thu, Nov 20, 2008 at 10:23 PM, Levi Rosol <levi....@gmail.com> wrote:
Decisions decisions decisions. Bruno, the way you describe was my initial plan (independent m/v/c's). I wanted to build it in such a way so that it could be added to the CE core easily, but on the same hand, for my purposes, the base functionality of a group will be nearly the same as a user. However I will be extending it tremendously as the Group object is really what my application will be built around.
Also, I don't see myself building it as a plug-in for CE. My application consists of CE as it's base, and my custom stuff on top of it. I would prefer CE to be the app, not the plugin, but it does function the way it is. I don't want to burry my stuff in the plug-in though.
Based on the reading i've done, I think a clean line of separation can be kept by taking the STI approach. Basically add a 'type' field to the User model, then go from there. It may even be worth while to abstract out the base functionality that both models will share, and inherit from that for both User and Group.
Then comes the question of Group membership. In my scenario, Users have friends and groups have members. If two Users are members of the same Group, they would be colleagues. When a User views another Users profile, they would see the Users friends as you already have them, and would have a separate box for colleagues. That not exactly how it would work, but it gets the idea across that colleagues are different than friends.
So that could involve inheriting from the Friendship model for the Member model. And I guess in that case, it may make more sense to have a separate, clean cut Group as all of the friendship stuff in the current User model is null and void for a Group.
I'm starting to ramble again. Is this making sense?
I think I'm to the point to where I just need to jump in and do it, and if it can be re-used in CE great. Either approach can be added to CE. It just depends on how much refactoring someone is willing to do to get it in there.
--
Sachin Kale
I like this direction .. how about this?
* Each user always belongs to a group
* Each group has roles associated with it 'a.k.a' photos, comments, blogs, etc
* If a user is being created and added explicitly to a group at the
same time, they get the set of roles associated with that group.
* If a user is self-sign up, they get the roles assigned by the CE
admin associated with a global or default group .. the default group
would be created at CE setup time.
* For multiple groups, the user gets the functionality of a group when
acting on a group created resource .. or if they are acting on a
resource that is not owned by any of the groups they belong to, they
get the default/global set of roles.
Also a huge task, but adds a lot of possibilities going forward,
including then having heirarchical groups and provides a consistent
relationship model throughout the system.
- Max
On Fri, Nov 21, 2008 at 12:18 AM, Levi Rosol <levi....@gmail.com> wrote:
> Max-
>
> I like where you're going with this, at least the hierarchy of groups part
> as that is ultimately where my application is heading.
>
> I'm not sure I'm seeing the benefit of having a global group. Some people
> may want to use CE as it is today. Users and Friends with no need for
> Groups. Having a global Group seems to be added complexity.
>
> Also, a Group will function differently than a User, or Profile as we
> started to describe earlier.
>
> But am I understanding you correctly?
I am seeing a group as an container for users and roles :), so it is
dual purpose, the global group just exists as a container for a
default set of roles so that the relationship model in this case would
be consistent and code wouldn't ahve to check to see if a user was in
a group or not in order to get roles for them .. does that clarify it
at all?
A profile can still be a 1-1 with a user, this just abstracts
functionality away from users and assigns it to a central class
(Group) that can act as both a way to associate users and a way to
associate roles .. all in one go.
So if a CE admin wanted to have no end user groups, that is fine :),
they just set up the roles for the global group and disable user
created groups and they are done.
This would also allow the CE overall admin to do varying levels of
administrative privileges using groups as well .. makes it easy to
make an admin who is just a forum/blog admin but who can't admin other
user profiles, or approve pending users if user signup moderation were
set up ... lets the CE admin create multi-level administration roles
for a CE instance.
- Max
Both :). Both a mapping of associations between related users and
roles for that association.
Groups would be the mapping between users and roles. A group would
have one or more users and 1 or more roles associated with it, it
would also have optional end user visibility.
So "People who Love Orange" would be a group of users that would have
roles (able to post to the people who love orange forum, see all
orange lover member blogs, and be visible to end users within CE ..
while "Forum administrators" would be a group of users with a set of
roles that would allow users in that group to moderate forums but
would not be end user visible ... only admins would see it.
A boolean attribute on the group class could indicate whether the
group is for end users or is an administrative role group.
At the RDBMS this could map to group table, user table, role table,
group_role table, and user_group table.
I helped implement a custom system years ago in java that had a
user/group/role object model very similar to this.
Not saying it is ideal for CE or the right path for CE now, but it is
a very flexible model that would give the end CE user many options for
customization ...

Very nice :)
Correct me if I'm wrong, but it seems like this implementation of
groups will be in the core of CE, effecting models, shuffling fields.
Will this be backwards compatible?
Is anyone working on a plugin based implementation of groups? Where a
group feature can be added or removed?
This would be much more conducive to the purposes that we use
community engine.
On Dec 2, 2:04 pm, "Levi Rosol" <levi.ro...@gmail.com> wrote:
> So now i have the following models:
>
> Group
> Membership
> GroupRole < Role
> Group_Permission
>
> Currently you can create a new Group. When you do, the current_user is added
> to the Membership collection and gets the Owner permission added.
> The index view lists the Groups
> When you view a group, you just see the Group info
>
> Next on my plate is to build out the Group profile page. I'll post my
> updates as I have them.
>
> Levi Rosol
> Twitter: @LeviRosol
>
> On Tue, Nov 25, 2008 at 9:15 AM, Levi Rosol <levi.ro...@gmail.com> wrote:
> > I started last night and should have something to show soon. I'm trying to
> > keep this initial run at this generic, and will worry about my project
> > specific stuff after i send it to you.
>
> > Levi
>
> > On Tue, Nov 25, 2008 at 9:01 AM, Bruno Bornsztein <
> > bruno.bornszt...@gmail.com> wrote:
>
> >> I don't plan on working on it anytime soon (not high on my priorities
> >> list). Let me know when you make some headway, I'd love to check out the
> >> repo.
> >> Thanks,
> >> Bruno
>
> >> On Mon, Nov 24, 2008 at 3:40 PM, Levi Rosol <levi.ro...@gmail.com> wrote:
>
> >>> Anyone planning to jump on this? If not, i will, but i can't put any
> >>> guarantees when it will be done as it will be a learning process for me
> >>> throughout.
>
> >>> Levi
>
> >>> On Fri, Nov 21, 2008 at 11:45 AM, Levi Rosol <levi.ro...@gmail.com>wrote:
>
> >>>> So how should we go about attacking this?
>
> >>>> Levi
>

>> > >> On Feb 4, 4:19 pm, Bruno Bornsztein <bruno.bornszt...@gmail.com>
>> > >> >http://github.com/bborn/communityengine/tree/groups
Does it have a new home?
thx!
Mike