Building on @adunsulag great work implementing modules for OpenEMR, I have developed significant additions to help support module management by developers.
New Module Manager(MM) capabilities:
- Landing page redesign where it is now a single page by combining the Unregistered and Registered tabs and auto registering modules. Example:
RE: 04/15/24 Restyled and added new action reset_module when the register icon is clicked. Also note new column for sql version extracted from the modules root file version.php. Also a new help action.
-
This is an important addition, please pay attention! Development of a manager actions event listener abstract class src/Core/AbstractModuleActionListener.php to include in the modules root directory. To take advantage simply extend in a class named and in a file named ModuleManagerListener.php.
If the class exist, the MM will call methods by its event name both before the MM does the action and after the action has completed regardless of the actions success or not.
Method names based on action are called with a “pre” prefix added to action name for events called before MM acts on the event.
Example are preenable(status), enable(status), predisable(status), disable(status) and so on. See abstract class for methods.
The intention is the class is used to allow module to clean up after itself for certain MM actions taken such as disable to make background task not active or to remove the tasks if module is unregistered(). See my examples included in the new Weno module.
I ask all developers of existing modules to take a look to see how this will help your module behave itself. -
New flag to change MM action buttons behavior. Too use, set flag in column mod_ui_active of the modules table. When flag is set the modules config settings cog icon will display with the Enable button so user can set up module if a config app is called when the modules support class moduleConfig.php script is called/required in a MM iFrame.
Besides having the icon available for normal config if the flag is set and the module is enable with the mod_active flag set the icon is turned red and spin. This is an alert to user that the modules setup may have errors needing attention. I used this in the Weno module to prevent module use in background until user completes setup. This is even if module is enabled too allow module to listen to core events.
To the user the module still needs to be enabled by keeping the Enable button active. To be clear; when the modules table entry has both mod_active and mod_ui_active flags set, the Enable button will remain and config icon will be in alert state until mod_ui_active flag is unset to 0.
-
I have included several helper methods as part of abstract class.
I will add more information here as I get time. Meanwhile any questions?
How to implement Module SQL Install and Upgrade. on 2024-03-09T05:00:00Z
I believe I have figured out the current workflow to show the Install and/or Upgrade SQL action buttons in MM. Here are some tips to keep in mind.
- First and foremost is including the version.php in module root. This file is similar to cores where required content is:
/**
* Module Weno EZ Integration versioning flat file.
* This file is used by the Modules installer for various reasons
* but not fully implemented.
* */
$v_major = '1';
$v_minor = '0';
$v_patch = '0';
$v_realpatch = '0';
$v_database = 0;
Will implement v_database soon so let’s start using.
- The version from file will only be written to module table entry when Install, Install SQL or Upgrade SQL is ran. Versioning will become clearer later below.
- For the Install Sql button to show sql/install.sql needs to be present. If present and regardless if the normal module install button or the newly shown Install Sql button is clicked, the install.sql will be ran. The difference is you still need to Install the module if install sql is used. Unsure what advantage we have here. Also note that the default table.sql will run depending if the install.sql is being used.
- For sql upgrading, version becomes important. The naming convention for sql upgrade file is
x_x_x-to-x_x_x_upgrade.sql. For the button to show, the table version entry needs to be below or equal to the file ‘from’ x.x.x version and the ‘to’ version should equal the version.php version. So table = 1.0.0, file = 1.1.0 and file name 1_0_0-to-1_1_0_upgrade.sql - After upgrade is ran the new version 1.1.0 will be recorded in table entry for module.
I will be adding a helper method to abstract listener class to allow automating the upgrade.
Another important note is that @adunsulag modified or improved the upgrading by creating and using the same classes and scheme used in our normal upgrading process making versioning of a little less import. I may see if I can port this from Laminas to custom in a helper method so modules can run upgrade sql bypassing MM.
If I’ve missed something or not communicating this well then I hear there’s a whole Jerry complaint website somewhere!