# Module HowTo - General module options

## 1. Account types

LAM currently provides three account types: users, groups, hosts
A module can manage one or more account types.
The types are specified with can_manage() or meta['account_types'].
Example:
Our ieee802Device module will be used only for host accounts.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // manages host accounts $return["account_types"] = array("host"); return $return; }

## 2. Base modules

In LDAP every entry needs exactly one structural object class. Therefore all modules which provide a structural object class are marked as base module.
This is done with is_base_module() or meta['is_base'].
Example:
The inetOrgPerson module manages the structural object class "inetOrgPerson" and therefore is a base module.
If your module is not a base module you can skip the meta data for this, default is false.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // base module $return["is_base"] = true; return $return; }

## 3. Alias name

The module name is very limited, therefore every module has an alias name. This alias name has no limitations and can be translated. It may contain special characters but make sure that it does not contain HTML special characters like "<".
The alias name can be the same for all managed account types or differ for each type.
The alias name is specified with get_alias() or meta['alias'].
Example:
Our ieee802Device module will get the alias MAC address.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // alias name $return["alias"] = _("MAC address"); return $return; }

## 4. Dependencies

Modules can depend on eachother. This is useful if you need to access attributes from other modules or the managed object classes of your module are not structural.
The dependencies are specified with get_dependencies() or meta['dependencies'].
Example:
Our ieee802Device module depends on the account module (because it is the only structural module at this time).

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // module dependencies $return['dependencies'] = array('depends' => array('account'), 'conflicts' => array()); return $return; }

## 5. Messages

There are many situations where you will display messages to the user. The modules should define such messages at a common place to make it easier to modify them without searching the complete file.
The baseModule offers the $messages variable for this. It should be filled by a function called load_Messages().
The baseModule will automatically check if you have implemented this function and call it at construction time.
Example:
Now let our ieee802Device module define a message.

/** * This function fills the error message array with messages */ function load_Messages() { $this->messages['mac'][0] = array('ERROR', 'MAC address is invalid!'); // third array value is set dynamically }

## 6. Managed object classes

##

You can tell LAM what object classes are managed by your module.
LAM will then check the spelling of the objectClass attributes and correct it automatically. This is useful if other applications (e.g. smbldap-tools) also create accounts and the spelling is differnt.
Example:
The ieee802Device module manages one object class.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // managed object classes $return['objectClasses'] = array('ieee802Device'); return $return; }

## 7. Known LDAP aliases

LDAP attributes can have several names (e.g. "cn" and "commonName" are the same). If you manage such attributes then tell LAM about the alias names.
LAM will then convert all alias names to the given attribute names automatically.
Example:
The posixGroup module manages the "cn" attribute. This attribute is also known under the alias "commonName".
This way the module will never see attributes called "commonName" because LAM renames them as soon as the LDAP entry is loaded.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // LDAP aliases $return['LDAPaliases'] = array('commonName' => 'cn'); return $return; }

##

## 8. Icon

You can specify a icon for you module. It will be displayed on the account pages and other module specific places (e.g. file upload).
The icons must be 32x32 pixels in size. The location is relative to the graphics directory.
Example:
The posixGroup module uses the "tux.png" from the graphics directory.

/** * Returns meta data that is interpreted by parent class * * @return array array with meta data */ function get_metaData() { $return = array(); // icon $return['icon'] = 'tux.png'; return $return; }

##