# Module HowTo - Account profiles

Account profiles make it easy to set default values for new accounts and even to reset an existing account to default values.
Your module should provide the possibility to define default values for all attributes which do not differ for each account.

## 1. Defining possible profile options

The first step to account profiles is defining the attributes for which the user can set default values. You will also have to define the type (text, checkbox, ...) of the profile options.
The profile editor then will display a fieldset for each module containing its profile options.
The profile options are specified with get_profileOptions() or meta['profile_options'].
Example:
The inetOrgPerson module has only two attributes which may be set to a default value: job title and employee type.
The other attributes are account specific and not useful as profile options.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // profile elements $return['profile_options'] = array( array( array('kind' => 'text', 'text' => _('Job title') . ":"), array('kind' => 'input', 'name' => 'inetOrgPerson_title', 'type' => 'text', 'size' => '30', 'maxlength' => '255'), array('kind' => 'help', 'value' => 'title')), array( array('kind' => 'text', 'text' => _('Employee type') . ":"), array('kind' => 'input', 'name' => 'inetOrgPerson_employeeType', 'type' => 'text', 'size' => '30', 'maxlength' => '255'), array('kind' => 'help', 'value' => 'employeeType')) ); [...]

This defines two text boxes in the profile editor, one for the job title and one for the employee type.
Your profile options should also provide a help link if the description of the input element might be not enough.

## 2. Checking user input

Probably you also want to check if the input data is syntactically correct.
The baseModule already provides different checks which can be activated with meta data. However you can also do the checking in the module.
Implementing the function check_profileOptions() in your module will allow you to do the checks yourself. Basic checks can be defined with meta['profile_checks'].
Example:
The inetOrgPerson module only needs some regular expression checks on the input. This can be done by the baseModule.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // profile checks $return['profile_checks']['inetOrgPerson_title'] = array( 'type' => 'ext_preg', 'regex' => 'title', 'error_message' => $this->messages['title'][0]); $return['profile_checks']['inetOrgPerson_employeeType'] = array( 'type' => 'ext_preg', 'regex' => 'employeeType', 'error_message' => $this->messages['employeeType'][0]); [...]

The type "ext_preg" means that the baseModule will use the get_preg() function in lib/account.inc for the syntax check. This function already contains regular expressions for the most common cases.

## 3. Loading an account profile

When an account profile is loaded the modules have to check what values they need for their internal data structures.
The baseModule already provides the possibility to store profile values directly as LDAP attributes in $this->attributes. This is done by defining profile-attribute mappings in meta['profile_mappings'].
If you have other values than LDAP attributes or need some post processing you can implement the function load_profile() in your module.
Example:
The inetLocalMailRecipient module only needs a static mapping. This can be done by the baseModule.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // profile mappings $return['profile_mappings'] = array( 'inetLocalMailRecipient_host' => 'mailHost' ); [...]

In this example the profile option "inetLocalMailRecipient_host" is stored as LDAP attribute "mailHost".

##