Hey SSers

I've read and tried a bunch of docs and posts (both forums and dev list) about extending Members, and see that the most suggested/preferable solution is to use DataObjectDecorator on Member rather than to SubClass it.. for good reason.

However, I need to do X, and I can see how that will work via subclassing but not sure if it can be done with the decorator.

The site is for an educational company, with system users, newsletter subscribers, and Students. I need to manage the student members in their own ModelAdmin and don't want the system/newsletter members to appear. Can I limit the scope of the ModelAdmin instance in this way?

Also, there is a big set of fields added to Member for Students, I really don't want these fields appearing in Member form for non-Students.

Currently, I've decorated Members with the extra stuff for students, but now realised that with Newsletter Subscribers being entered as members belonging to newsletter groups, that these members (possibly random public users) would appear in the Members Admin I've created. I'd be happy to decorate in a "member-type" field that specifies "Student", but I couldn't figure out how to restrict the ModelAdmin to this type.

Subclassing I imagine would give me what I'm after (i think), but comes with the cons listed elsewhere. Has anyone run into this before? Any suggestions?

Sorry this probably seems a bit scatty, my head is going crazy trying to figure this out! The permissions/groups/roles for these students (differing programmes, ranks, stages) is quite complicated too! I'm getting there but help/advice/suggestions would be tres appreciated

dizzy

[reposted from General Questions section, thought it might be more appropriate in Customising the CMS]

Hi Dizzy

There is actually an example of extending Member for use in model admin in the SilverStripe book. I have also done it for one project and it seems to work ok, the only issue I have found is that when adding users into model admin you need to make sure you are not repeating any email addresses as this will not be checked by SS like it will when entering members in the security section.

Other than that it works for me, I have a number of DataObjects attached to my member and as long as I check the ClassName is my member subclass (User in this example) before trying to access them then it works as expected, for example to access the attached Lesson DataObjects:

		if(Member::currentMember() && Member::currentMember()->ClassName == 'User'){
			$Lessons = Member::currentMember()->Lessons();
                }

Hope that helps

Aram

In the german book they say (page 231 RegistrationDetailsStep.php) you also could use the Member_Validator for the EmailField (has to be a EmailField) - this should check if the email is unique.

function getValidator() {
return new Member_Validator(
'Firstname',
'Email'
);
}

Hi Lerni,

As I understand it that is for the front end registration form validation and does not work in ModelAdmin. In the english book it's on page 187, and is added to RegistrationDetailStep class not the Member sub class.

Or am I missing something?

Aram

Hi Aram

You are right - I was writing faster than thinking :-(

Hi Aram

Thanks so much for your reply. SSbits.com is outstanding, btw :)

Yeah, I had come up against the ModelAdmin email address issue when I was testing a few combinations of options. Sounds like the method you've described (the Developer example from the SS book) is the way to go in this instance.. but, sigh, I am concerned about the email address problem.

I just won't be able to trust these CMS users not to duplicate email addresses. Is there anyway you can think of that I can port across the existing check in the Security Admin into this Subclassed Members' ModelAdmin?

The subclass check will come in handy, good call. Thanks!

Just letting subscribers to the thread know I'm still running into troubles with managing Members, whether they're decorated or subclassed. I have started a new thread here -> http://silverstripe.org/customising-the-cms/show/282214