Module HowTo - Configuration options


There might be situations where you want to give the user the possibility to make general settings which are not useful to place on the account detail pages or profile editor.
Therefore LAM allows the modules to define their own configuration options. E.g. the posixAccount module uses this to define the ranges for the UIDs.
LAM will display your configuration options only if the user also selected your module.

1. Defining configuration options

First you have to define what options you want to offer the user. LAM will display all options in one fieldset for each module. Please notice that there will be no separation on account types if you module is suitable for different account types.

The configuration options are specified with get_configOptions() or meta['config_options'].

Example:

The posixGroup module offers several configuration options including the min/maximum values for GIDs.

    /**
    * Returns meta data that is interpreted by parent class
    *
    * @return array array with meta data
    */
    function get_metaData() {
        $return = array();
        // configuration options
        $configContainer = new htmlTable();
        $configContainer->addElement(new htmlSubTitle(_("Groups")), true);
        $minGidInput = new htmlTableExtendedInputField(_('Minimum GID number'), 'posixGroup_minGID', null, 'minMaxGID');
        $minGidInput->setRequired(true);
        $configContainer->addElement($minGidInput, true);
        $maxGidInput = new htmlTableExtendedInputField(_('Maximum GID number'), 'posixGroup_maxGID', null, 'minMaxGID');
        $maxGidInput->setRequired(true);
        $configContainer->addElement($maxGidInput, true);
        $return['config_options']['group'] = $configContainer;
        [...]

The min/maximum GID numbers are defined with simple text boxes.

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_configOptions() in your module will allow you to do the checks yourself. Basic checks can be defined with meta['config_checks'].

Example:

The posixGroup module only needs to check if the GID numbers are correct. The password hash type needs not to be checked as it is a selection.

    /**
    * Returns meta data that is interpreted by parent class
    *
    * @return array array with meta data
    */
    function get_metaData() {
        $return = array();
        // configuration checks
        $return['config_checks']['group']['posixGroup_minGID'] = array (
            'type' => 'ext_preg',
            'regex' => 'digit',
            'required' => true,
            'required_message' => $this->messages['gidNumber'][5],
            'error_message' => $this->messages['gidNumber'][5]);
        $return['config_checks']['group']['posixGroup_maxGID'] = array (
            'type' => 'ext_preg',
            'regex' => 'digit',
            'required' => true,
            'required_message' => $this->messages['gidNumber'][6],
            'error_message' => $this->messages['gidNumber'][6]);
        $return['config_checks']['group']['cmpGID'] = array (
            'type' => 'int_greater',
            'cmp_name1' => 'posixGroup_maxGID',
            'cmp_name2' => 'posixGroup_minGID',
            'error_message' => $this->messages['gidNumber'][7]);
        [...]

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.
To check if the minimum GID is smaller than the maximum GID we define a check for the nonexistent option "cmpGID" and define it as optional. This will do the comparison check.