This document describes the module interface for LDAP Account Manager



1. Location and naming of modules

All LAM modules are placed in lib/modules/ and are named "<class name>.inc".
E.g. if you create a new module and its class name is "qmail" then the filename would be "qmail.inc".

The class name of a module must contain only a-z, A-Z, 0-9, -, and _.


2. Class functions

2.1. Static functions

These functions are called without instanciating an object of the module class. They must not depend on class variables and are only allowed to call other static functions.


2.1.1. can_manage


function can_manage($scope)

Returns true if this module can manage accounts of type $scope, otherwise false.
The $scope parameter defines the account type ("user", "group", "host" at this time).


2.1.2. get_alias


function get_alias($scope)

This function returns a more descriptive string than the class name. Alias names are used for the buttons of the account pages and the module selection of the configuration wizard.
Please take care that your alias name is not too long. It may contain a-z, A-Z, 0-9, -, _ and spaces.
The $scope parameter defines the account type ("user", "group", "host" at this time).

2.1.3. is_base_module


function is_base_module($scope)

Returns true if your module is a base module and otherwise false.
$scope is the account type ("user", "group", "host" at this time).

Every account type needs at least one base module. A base module defines a full qualified account.
E.g. modules that use the object class posixAccount may be base modules as it makes sense to manage these Unix accounts. On the other hand the quota module is no base module as it needs posixAccount.

2.1.4. get_ldap_filter


function get_ldap_filter($scope)

Returns a string that can be used as part of a LDAP filter. Usually used to filter object classes.
$scope is the account type ("user", "group", "host" at this time).

All filter parts of the base modules are combined with OR and used to find the accounts for the lists.

Example: return "(objectClass=posixAccount)"

This function is only used for base modules. Standard modules do not need to implement it.

2.1.5. get_dependencies


function get_dependencies($scope)

This function returns a list of modules it depends on.
The $scope parameter defines the account type ("user", "group", "host" at this time).

The return value is an array with two sub arrays, "depends" and "conficts".
All values of the conflict array are string values with module names.
All values of the depends array are either string values with module names or arrays which include only string values with module names. If an element of the depends array is itself an array, this means that your module depends on one of these modules.

Example: return array("depends" => array("posixAccount", array("qmail", "sendmail")), "conflicts" => array("exim"));

2.1.6. get_profileOptions


function get_profileOptions($scope)

This function defines what attributes will be used in the account profiles and their appearance in the profile editor.

$scope is the account type ("user", "group", "host" at this time).
The return value is an array that contains meta HTML code.

The type "fieldset" is not allowed here.
The name attributes are used as keywords to load and save profiles. We recommend to use the module name as prefix for them (e.g. posixAccount_homeDirectory) to avoid naming confilcts.

2.1.7. check_profileOptions


function check_profileOptions($scope, $options)

This function checks the input for a new or modified account profile.

$scope is the account type ("user", "group", "host" at this time).
$options is an hash array (option name => value) that contains the input. The option values are all arrays containing one or more elements.
If the input data is invalid the return value is an array that contains arrays to build StatusMessages (0 => message type, 1 => message head, 2 => message text, 3 => additional variables).
If no errors occured the function returns an empty array.


2.2. Class functions

2.2.1. Constructor


function <module name> ($base)

Every module needs a constructor that has an account container as argument $base.
With this account container you can interact with other modules and use several helper functions.

2.2.2. module_ready


function module_ready()

Your module might depend on input of other modules. This function determines if the module button on the account page is active or not.
The return value is true if your module accepts input, otherwise false.

2.2.3. module_complete


function module_complete()

This function is called after your module has processed the POST input data.
If there was an input error and you want to display a page again then return false. If true is returned the next module page will be displayed.

2.2.4. get_help


function get_help($helpID)

This function is called when a page requests a help topic from this module.
$scope is the help identifier; it must only contain a-z, A-Z, 0-9 -, . and _.
It must return the help entry as array for the submitted help identifier. The format of the array to be returned is described in section 4. "Help entry syntax".


3. Meta HTML code

The modules are not allowed to display HTML code directly but return meta HTML code. This allows to have a common design for all module pages.
Meta HTML code is always returned as a three dimensional array[a][b][c] where a is the row number, b is the coumn number and c is is a data elememt.

Format for data elements:

A data element is an array which contains the data to display.
All data elements must contail a value "kind" which defines what kind of element should be displayed.

These are the possibilies for kind and what other options are implicated:


Beneath those values a "td" value may be added. This has to be an array with one or more of these options:


Example:

array(
  array(
    array("kind" => "text", "text" => "This is an example", "td" => array("colspan" => 3))
  ),
  array(
    array("kind" => "text", "text" => "Input:"),
    array("kind" => "input", "name" => "myinput", "type" => "text"),
    array("kind" => "help", "value" => "42")
  )
)



4. Help entry syntax

The array that is returned by the get_help function must follow the below described syntax. Fields marked REQUIRED are neccessary under any circumstances. Fields marked OPTIONAL may be left out when not needed.
There are basically two different types of help entries that can be used. Internal help entries, that means the headline, text, etc is included in the help entry or external help entries, that means the help entry has only a reference pointing to a HTML/PHP page that offers the help entry.


4.1. Internal help entries

ext (REQUIRED)
Must be FALSE in this case.

Headline (REQUIRED)
The headline of this help entry. Can consist of any alpha-numeric characters. No HTML/CSS elements are not allowed here.

Text (REQUIRED)
The text of this help entry. Can constist if any alpha-numeric characters and can contain placeholder for variables passed to this help entry. The placeholder must follow the syntax for placeholder defined by the PHP printf function. HTML/CSS elements are allowed here as long as they follow the XHTML1.0 Strict specification.

Variables (OPTIONAL)
An array of variables used as arguments for the formated string submitted in the Text field. This may be but must not be an assiciated array where each argument to be passed on is a single row in the array. This array may only consist of types that can be passed as arguments to PHP's printf function.

SeeAlso (OPTIONAL)
An array of references to anonther related subjects. Each row of the array must contain a field called "text" with the text that should be displayed and may contain a field called "link" which is used as value for the href attribute of a HTML tag when set.


4.2. External help entries

ext (REQUIRED)
Must be TRUE in this case.

Link (REQUIRED)
The complete filename of the file stored under the help/ directory which should be displayed when this help entry is called.