2011-02-07 07:48:44 +01:00
|
|
|
# Member
|
|
|
|
|
|
|
|
## Introduction
|
|
|
|
|
2011-03-08 22:05:51 +01:00
|
|
|
The `[api:Member]` class is used to represent user accounts on a SilverStripe site (including newsletter recipients).
|
2011-02-07 07:48:44 +01:00
|
|
|
|
|
|
|
## Testing For Logged In Users
|
|
|
|
|
2011-03-08 22:05:51 +01:00
|
|
|
The `[api:Member]` class comes with 2 static methods for getting information about the current logged in user.
|
2011-02-07 07:48:44 +01:00
|
|
|
|
|
|
|
**Member::currentUserID()**
|
|
|
|
|
|
|
|
Retrieves the ID (int) of the current logged in member. Returns *0* if user is not logged in. Much lighter than the
|
|
|
|
next method for testing if you just need to test.
|
|
|
|
|
|
|
|
:::php
|
|
|
|
// Is a member logged in?
|
|
|
|
if( Member::currentUserID() ) {
|
|
|
|
// Yes!
|
|
|
|
} else {
|
|
|
|
// No!
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
**Member::currentUser()**
|
|
|
|
|
|
|
|
Returns the full *Member* Object for the current user, returns *null* if user is not logged in.
|
|
|
|
|
|
|
|
:::php
|
|
|
|
if( $member = Member::currentUser() ) {
|
|
|
|
// Work with $member
|
|
|
|
} else {
|
|
|
|
// Do non-member stuff
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Subclassing
|
|
|
|
|
|
|
|
<div class="warning" markdown="1">
|
2011-04-15 11:35:30 +02:00
|
|
|
This is the least desirable way of extending the `[api:Member]` class. It's better to use `[api:DataExtension]`
|
2011-03-08 22:05:51 +01:00
|
|
|
(see below).
|
2011-02-07 07:48:44 +01:00
|
|
|
</div>
|
|
|
|
|
2011-03-08 22:05:51 +01:00
|
|
|
You can defined subclasses of `[api:Member]` to add extra fields or functionality to the built-in membership system.
|
2011-02-07 07:48:44 +01:00
|
|
|
|
|
|
|
:::php
|
|
|
|
class MyMember extends Member {
|
|
|
|
static $db = array(
|
|
|
|
"Age" => "Int",
|
|
|
|
"Address" => "Text",
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
To ensure that all new members are created using this class, put a call to `[api:Object::useCustomClass()]` in
|
|
|
|
(project)/_config.php:
|
|
|
|
|
|
|
|
:::php
|
|
|
|
Object::useCustomClass("Member", "MyMember");
|
|
|
|
|
|
|
|
Note that if you want to look this class-name up, you can call Object::getCustomClass("Member")
|
|
|
|
|
|
|
|
## Overloading getCMSFields()
|
|
|
|
|
|
|
|
If you overload the built-in function getCMSFields(), then you can change the form that is used to view & edit member
|
2011-10-28 03:37:27 +02:00
|
|
|
details in the newsletter system. This function returns a `[api:FieldList]` object. You should generally start by calling
|
|
|
|
parent::getCMSFields() and manipulate the `[api:FieldList]` from there.
|
2011-02-07 07:48:44 +01:00
|
|
|
|
|
|
|
:::php
|
|
|
|
function getCMSFields() {
|
|
|
|
$fields = parent::getCMSFields();
|
|
|
|
$fields->insertBefore(new TextField("Age"), "HTMLEmail");
|
|
|
|
$fields->removeByName("JobTitle");
|
|
|
|
$fields->removeByName("Organisation");
|
|
|
|
return $fields;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
## Extending Member or DataObject?
|
|
|
|
|
2011-03-08 22:05:51 +01:00
|
|
|
Basic rule: Class `[api:Member]` should just be extended for entities who have some kind of login.
|
|
|
|
If you have different types of `[api:Member]`s in the system, you have to make sure that those with login-capabilities have
|
2011-02-07 07:48:44 +01:00
|
|
|
unique email-addresses (as this is used for login-credentials).
|
2011-03-08 22:05:51 +01:00
|
|
|
For persons without login-capabilities (e.g. for an address-database), you shouldn't extend `[api:Member]` to avoid conflicts
|
|
|
|
with the Member-database. This enables us to have a different subclass of `[api:Member]` for an email-address with login-data,
|
2011-02-07 07:48:44 +01:00
|
|
|
and another subclass for the same email-address in the address-database.
|
|
|
|
|
2011-04-15 11:35:30 +02:00
|
|
|
## Member Role Extension
|
2011-02-07 07:48:44 +01:00
|
|
|
|
|
|
|
Using inheritance to add extra behaviour or data fields to a member is limiting, because you can only inherit from 1
|
2011-04-15 11:35:30 +02:00
|
|
|
class. A better way is to use role extensions to add this behaviour.
|
2011-02-07 07:48:44 +01:00
|
|
|
|
|
|
|
:::php
|
2011-04-15 11:35:30 +02:00
|
|
|
Object::add_extension('Member', 'ForumRole');
|
2011-02-07 07:48:44 +01:00
|
|
|
// OR
|
|
|
|
Member::add_role('ForumRole');
|
|
|
|
|
2011-04-15 11:35:30 +02:00
|
|
|
A role extension is simply a subclass of `[api:DataExtension]` that is designed to be used to add behaviour to `[api:Member]`.
|
2011-02-07 07:48:44 +01:00
|
|
|
The roles affect the entire class - all members will get the additional behaviour. However, if you want to restrict
|
|
|
|
things, you should add appropriate `[api:Permission::checkMember()]` calls to the role's methods.
|
|
|
|
|
|
|
|
:::php
|
2011-04-15 11:35:30 +02:00
|
|
|
class ForumRole extends DataExtension {
|
2011-02-07 07:48:44 +01:00
|
|
|
/**
|
|
|
|
|
|
|
|
* Modify the field set to be displayed in the CMS detail pop-up
|
|
|
|
*/
|
2011-10-28 03:37:27 +02:00
|
|
|
function updateCMSFields(FieldList $currentFields) {
|
2011-02-07 07:48:44 +01:00
|
|
|
// Only show the additional fields on an appropriate kind of use
|
|
|
|
if(Permission::checkMember($this->owner->ID, "VIEW_FORUM")) {
|
2011-10-28 03:37:27 +02:00
|
|
|
// Edit the FieldList passed, adding or removing fields as necessary
|
2011-02-07 07:48:44 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function extraStatics() {
|
|
|
|
// Return an array containing keys 'db', 'has_one', 'many_many', 'belongs_many_many',
|
|
|
|
}
|
|
|
|
|
|
|
|
function somethingElse() {
|
|
|
|
// You can add any other methods you like, which you can call directly on the member object.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
## API Documentation
|
|
|
|
|
|
|
|
`[api:Member]`
|