Fork me on GitHub


Small features can be grouped into modules and managed, enabled and upgraded, without impacting the entire site.

A number of modules have already been created, here is the current list:

Name Description
Active Directory Inspector A simple Active Directory browser.
Legacy Client Support Provide a way to block or warn users to upgrade, based on the Web Browser used.
Reports Users Provides some reports on users and their permissions for admin purpose.
Reservation Allows the management of reservable items.
SQL Utils A set of utility functions and classes to help interact with SQL Servers.

Module conventions

In order to avoid conflicts some naming conventions are recommended below:

Module name: The module name should be composed of the prefix "LESK-Module" followed by the module namespace as defined in the composer.json of the module. Both parts should be separated by an underscore "_". For example, "LESK-Module_ActiveDirectoryInspector" in the case of the "Active Directory Inspector" module.

Module tables: Keeping in mind the limitations of the underlying RDBMS systems, in particular, Oracle DB limits database objects names to 30 bytes. Module table names should be composed of the prefix "mod", followed by a unique and short identifier for the module for example "adinsp" and finally the name of the table. All parts should be separated by an underscore "_". The total length should remain under 30 characters. For example, the full table name for the module could be "mod_adinsp_users" or "mod_adinsp_groups"

Module settings: Module settings should be composed of the lower case slug of the module, followed by the setting variable itself. All parts should be separated by a period ".". For example two settings for the "Active Directory Inspector" module are "active_directory_inspector.account_suffix" and "active_directory_inspector.port".

Additional documentation can be found on the lesk-modules and look at a concrete example such as the Active Directory Inspector module for more details.