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:
|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.|
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".