Hi guys, before things get too complicated, here's more of what I had in mind:
Profile is just a container for things that go on the profile page for a group or user, and has a polymorphic association (so it can be associated with anything, really). Users stay the same, group is a new object, and users belong to a group through a Membership, which also describes the users Role in the group (admin, moderator, member) via the existing Roles table. Make sense? On Fri, Nov 21, 2008 at 1:29 AM, Levi Rosol <[EMAIL PROTECTED]> wrote: > Attached is a PDF I slapped together tonight giving a rough idea of the > structure of what we described in this thread. > > Couple things to note: > > The existing Roles (think of these as system roles) get tied to a user via > a Permissions table. This isn't necessary for the discussion at hand, but > could be further expanded to cover what Max is talking about. > > User drops a number of fields. All of which get moved to Profile. Some of > which also end up in Group. > > Relationships is the current Friendships model renamed. Added a 'type' > field and a group_id and profile_id. This would allow Relationships to > handle Friends for the Profiles and Members for the Groups using the single > table inheritance > (STI<http://wiki.rubyonrails.com/rails/pages/SingleTableInheritance>) > pattern. > > Although it's not on this diagram, it would be possible to create security > at the Relationship level if needed. On the Group side, think of a Group > Admin, Moderator, ??? roles. I'm not sure this is needed on the Profile > side, so there wouldn't be a need to implement it. But the option is always > there. This would further expand the functionality described by Max. > > One thing that is missing is the ability to create a Group under another > Group. For the core, this isn't nesessary, but would be easy to add using a > Self > Referential Many To Many > Relationship<http://wiki.rubyonrails.org/rails/pages/HowToCreateASelfReferentialManyToManyRelationship> > > Then I threw in the Photos model. I added a 'type' field to the model, and > then the profile_id and group_id columns. As with Relationships, this would > allow us to keep all data for both in one place, differentiating by the > type, using the STI pattern > > Forums/topics/post, blog, comments, would all tie to the appropriate model > (either Profile or Group, or both) in a similar fashion as the Photos. > > thoughts? > > > ... I need sleep... > > -- > Levi Rosol > > Twitter: @LeviRosol <http:www.twitter.com/LeviRosol> > > > > On Fri, Nov 21, 2008 at 12:03 AM, Max Schubert <[EMAIL PROTECTED]>wrote: > >> >> On Fri, Nov 21, 2008 at 12:35 AM, Levi Rosol <[EMAIL PROTECTED]> >> wrote: >> > forgive me if i'm being dense. I think what you're describing is a Group >> in >> > a role based security sense. Meaning all users belong to a global group >> as a >> > user, but then a CE admin could create another group, assign people to >> it, >> > and give that group a role. >> > >> > Is that correct? >> >> 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 ... >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CommunityEngine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/communityengine?hl=en -~----------~----~----~----~------~----~------~--~---
