Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Data Model Questions /

Member Ext/SubClass/Groups Confusion


Reply


5 Posts   1410 Views

Avatar
dizzystuff

Community Member, 93 Posts

10 February 2011 at 6:05pm

Edited: 10/02/2011 6:07pm

Hi All

I have a few questions about extending the Member datamodel that are assploding my brain!

I have been reading and reading and reading posts in the forums / docs / blogs / dev-list about Extending vs Subclassing the Member object but I'm still struggling to figure out the correct application of this info to what I need to build.

Firstly, I have three primary types of Members - developers, contacts and staff. A Member can be any combination of these.

I'm not overly concerned about the Security tab in the admin as the plan is to have candidate and contact creation on the front end. Though staff would potentially be added via that tab (probably - but not necessary). Initially these Members will be logging in to keep their information up to date, so a profile page is also required - but obviously needs to only show the fields appropriate to the type/s of Member logged in...

If I've extended Member with multiple 'roles', what is the best method for me to determine which one/s they are?

As the app progresses they will have access to different areas of the site upon logging in.

Linking developers and contacts to companies and fellow developers and contacts - ie maintaining a range of relationships - will be critical too. At the end of the day this will end up as effectively a CRM. A contact will have a parent company but may be associated with others too, just as a developer may be associated with other companies but not require a parent. Both would have a primary link to a staff member.

eek! My brain is assploding. Please help if possible!

Avatar
Willr

Forum Moderator, 5513 Posts

10 February 2011 at 8:30pm

A Member can be any combination of these.

If they can be more than 1 of those then I would suggest decorators are the way to go because you can't have a member record which has both a 'Developer' and 'Contact' instance.

As the app progresses they will have access to different areas of the site upon logging in.

Use the Group metaphor to work out what permissions a user has. I would setup a group for each of your member types then in your permission system assign Roles, permissions to groups rather than members.

Ref:
http://doc.silverstripe.org/sapphire/en/reference/member
http://doc.silverstripe.org/sapphire/en/reference/permission

Avatar
dizzystuff

Community Member, 93 Posts

10 February 2011 at 10:56pm

Hey Willr

Ok, cool. That makes sense to me, but does raise extra questions.

After re-reading a bunch of the posts re extending Member this arvo, I thought perhaps I could do it by extending Member with a "MemberExtender" which adds 1:1 relations between the Member class and a DO for each type - ie DeveloperRole, ContactRole, StaffRole. (rather than creating those as decorators themselves on to Member like ForumRole).

But I'm not sure if there's much advantage to that? At first I was certain, now I'm confused lol/sigh. As you can see, my prob today is that I might've been overthinking it all.

The advantage I see, firstly, is that the Member table then wouldn't get stuffed full of the columns for each member type. But while it irks me, I don't really see that as a huge deal. It irks me though. More importantly, would it make it easier to tell which of these roles the Member belongs to?

(how would I be able to tell which of the roles the Member belonged to in your suggestion?)

... ah I've just figured the answer to my own question I think, I'd assign them Groups and could then query those groups for which type they were, right? But am I losing anything by doing this? It feels like I should have that definition closer to the Member rather than just adding them to the group. That is, shouldn't I be able to get a Member and figure out what type/s they are separate to their Groups?

I guess I'm concerned about data integrity, I need to make sure someone who is a Contact must have a parent company, for example. So in this scenario it means I can't just allow users to go into the Security tab and add someone to a 'Contact' group. So from that it basically means I'll need to decommission that tab altogether and build a different admin for this?

Hope that hasn't all come out sounding too much like the ramblings of a mad man, and I really appreciate your help while I learn and get my head around this stuff. It seems I have trouble extending/etc Member in every damn project! But I get there eventually.

Avatar
Willr

Forum Moderator, 5513 Posts

12 February 2011 at 12:28am

The advantage I see, firstly, is that the Member table then wouldn't get stuffed full of the columns for each member type. But while it irks me, I don't really see that as a huge deal. It irks me though. More importantly, would it make it easier to tell which of these roles the Member belongs to?

(how would I be able to tell which of the roles the Member belonged to in your suggestion?)

Like I said, you would use Groups to classify the type of member. So a Member "Jane" could be in the "Developers" group and inherit those permissions. The permission system works around 'Roles' and 'Permissions' assigned to group objects. This is usually the most flexible and easy to manage setup.

I guess I'm concerned about data integrity, I need to make sure someone who is a Contact must have a parent company, for example. So in this scenario it means I can't just allow users to go into the Security tab and add someone to a 'Contact' group. So from that it basically means I'll need to decommission that tab altogether and build a different admin for this?

You could probably get a ModelAdmin interface for that setup pretty quick but also have a look at getValidator() for your model record, you may be able to define Company as required within the existing Security.

Avatar
dizzystuff

Community Member, 93 Posts

13 February 2011 at 4:50pm

Ok, gotcha about the groups/roles/permissions and I'll check out getValidator().

Just one more question :)

When it comes to extending Member with the fields/etc for Developer, Contact, Staff, etc:

extending Member with a "MemberExtender" which adds 1:1 relations between the Member class and a DO for each type - ie DeveloperRole, ContactRole, StaffRole. (rather than creating those as decorators themselves on to Member like ForumRole).

I see this as almost the same as your suggestion but avoids all the null columns on Members - would you anticipate any extra problems/challenges I'd face doing it this way? (or conversely are there specific advantages to just adding the fields directly onto Member?)