Jump to:

3373 Posts in 998 Topics by 712 members

Data Model Questions

SilverStripe Forums » Data Model Questions » Member Ext/SubClass/Groups Confusion

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1
Go to End
Author Topic: 1254 Views
  • dizzystuff
    Avatar
    Community Member
    93 Posts

    Member Ext/SubClass/Groups Confusion Link to this post

    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!

  • Willr
    Avatar
    Forum Moderator
    5462 Posts

    Re: Member Ext/SubClass/Groups Confusion Link to this post

    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

  • dizzystuff
    Avatar
    Community Member
    93 Posts

    Re: Member Ext/SubClass/Groups Confusion Link to this post

    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.

  • Willr
    Avatar
    Forum Moderator
    5462 Posts

    Re: Member Ext/SubClass/Groups Confusion Link to this post

    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.

  • dizzystuff
    Avatar
    Community Member
    93 Posts

    Re: Member Ext/SubClass/Groups Confusion Link to this post

    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?)

    1254 Views
Page: 1
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.