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