Details
Story
Major
Description
- Add a new optional feature for modules to support an automation method that may be called at a given interval by Blesta cron
- Allow Input errors to be set? And if they are, include them in the cron log? Or simply assume the module will write errors to monolog?
- Add a new core cron task to call the automation method on all installed modules
Things to consider:
- Modules are much similar to plugins now, and differentiating them while merging similar features may require refactoring (something to do in a major release)
- Modules need database access. Loading the Record component may not suffice, and an instance of it may need to be provided instead
- Logging mechanisms may need to be provided to the module and its automation task
- Backward compatibility must be maintained
- Modules may need more flexibility with automation tasks, such as better support for running multiple tasks, or knowledge of the last time a particular task was last run (like a normal cron task). It would not have this information unless it creates database tables and maintains it itself.
- It may need to integrate similar install/upgrade/uninstall functionality as plugins
TODO:
- Update Modules to support a new method, cron($key), similar to plugins. Default to do nothing
- Refactor CronTasks and the `plugin_dir` column to support modules
- Add a `type` column, ENUM(system, plugin, module), default system, after `key`
- Rename the `plugin_dir` column to `dir`.
- Update the unique index for (`key`, `plugin_dir`) to (`key`, `type`, `dir`)
- Update for backward compatibility
- Update all returned objects to contain a 'plugin_dir' column. If `type` is 'plugin' then set 'plugin_dir' to the value of 'dir', otherwise null. TEST
- Update existing CronTasks methods and queries that use 'plugin_dir' to continue to work as before. TEST
- Add any new methods necessary to implement the same functionality on the new structure. Deprecate existing methods accordingly. TEST
- Update all core system calls to CronTasks to use the new methods. TEST
- (Create new tasks for each core plugin that uses cron tasks to update them accordingly)
- Add a new task when the cron runs for running module tasks, similar to plugin cron tasks. TEST
Consider allowing modules to create their own automation tasks. Such automation tasks could call methods within the module that registers the automation task to perform some action.
Or, maybe this could be abstracted such that there is a built in module automation task that calls such methods within each module on a regular basis so the module can perform such actions if it desires.
Requires some discussion
Activity
This sounds like a difficult task to integrate. Modules will need database access, similar to plugins, and this will probably change module design requirements and make them backward-incompatible with the current design. This also raises the question of the difference between modules and plugins and would likely lead to other refactoring.
This task may also be dependent on cron task refactoring in CORE-2518.
The alternative, which I kind of prefer, would allow a single built-in automation task that goes through installed modules and executes a specific method within them, if it exists. The module would handle its own scheduling, but the core automation task would bear the burden and not the module.
Would this be backwards incompatible? Or is it possible to ignore modules that do not implement this?
Paul Phillips
added a comment - This sounds like a difficult task to integrate. Modules will need database access, similar to plugins, and this will probably change module design requirements and make them backward-incompatible with the current design. This also raises the question of the difference between modules and plugins and would likely lead to other refactoring.
This task may also be dependent on cron task refactoring in CORE-2518.
The alternative, which I kind of prefer, would allow a single built-in automation task that goes through installed modules and executes a specific method within them, if it exists. The module would handle its own scheduling, but the core automation task would bear the burden and not the module.
Would this be backwards incompatible? Or is it possible to ignore modules that do not implement this? The alternative, which I kind of prefer, would allow a single built-in automation task that goes through installed modules and executes a specific method within them, if it exists. The module would handle its own scheduling, but the core automation task would bear the burden and not the module.
Blesta would have to go through every service in the system at every time interval, load the associated module, and make a call to it. The performance cost would be much higher than if an automation task were registered and run instead.
If the module must determine things like scheduling, it would be better to have support for general scheduling methods so every module doesn't have to roll their own. Also, the module would need to know the last time it was called on this service to determine whether it should run now. It would have to run queries for this so it would need database access provided to it.
Would this be backwards incompatible? Or is it possible to ignore modules that do not implement this?
We could add support for an optional method on the module so it could be backward-compatible, however, the module needs to be provided database access similar to plugins, and that could still be backward-incompatible since Blesta core would need to set it on a new model class for the module.
An optional method could also be added to modules to support registering automation tasks, but several changes to the core would be necessary to support it. The potential backward-incompatiblities typically stem from the design changes that would be necessary to provide the module access to additional data like an instance of the Record object.
Tyson Phillips (Inactive)
added a comment -
The alternative, which I kind of prefer, would allow a single built-in automation task that goes through installed modules and executes a specific method within them, if it exists. The module would handle its own scheduling, but the core automation task would bear the burden and not the module.
Blesta would have to go through every service in the system at every time interval, load the associated module, and make a call to it. The performance cost would be much higher than if an automation task were registered and run instead.
If the module must determine things like scheduling, it would be better to have support for general scheduling methods so every module doesn't have to roll their own. Also, the module would need to know the last time it was called on this service to determine whether it should run now. It would have to run queries for this so it would need database access provided to it.
Would this be backwards incompatible? Or is it possible to ignore modules that do not implement this?
We could add support for an optional method on the module so it could be backward-compatible, however, the module needs to be provided database access similar to plugins, and that could still be backward-incompatible since Blesta core would need to set it on a new model class for the module.
An optional method could also be added to modules to support registering automation tasks, but several changes to the core would be necessary to support it. The potential backward-incompatiblities typically stem from the design changes that would be necessary to provide the module access to additional data like an instance of the Record object. Blesta would have to go through every service in the system at every time interval, load the associated module, and make a call to it. The performance cost would be much higher than if an automation task were registered and run instead.
Why? Couldn't it call the module only? The module would be responsible for doing anything to services that need to be done. Maybe the module needs to perform some action and doesn't care about its services.
We could add support for an optional method on the module so it could be backward-compatible, however, the module needs to be provided database access similar to plugins, and that could still be backward-incompatible since Blesta core would need to set it on a new model class for the module.
An optional method could also be added to modules to support registering automation tasks, but several changes to the core would be necessary to support it. The potential backward-incompatiblities typically stem from the design changes that would be necessary to provide the module access to additional data like an instance of the Record object.
Whatever we do we need to maintain backwards compatibility. Allowing the module to register an automation task would be most flexible as Blesta would handle the scheduling automatically and the frequency or time the tasks run would be configurable in the standard place.
If database access cannot be granted without introducing a backwards incompatible change, perhaps a method in the core could be provided that allows the module to search/select/update related services. Maybe we don't want services to be able to perform any query under the sun, which could prove dangerous.
Paul Phillips
added a comment - Blesta would have to go through every service in the system at every time interval, load the associated module, and make a call to it. The performance cost would be much higher than if an automation task were registered and run instead.
Why? Couldn't it call the module only? The module would be responsible for doing anything to services that need to be done. Maybe the module needs to perform some action and doesn't care about its services.
We could add support for an optional method on the module so it could be backward-compatible, however, the module needs to be provided database access similar to plugins, and that could still be backward-incompatible since Blesta core would need to set it on a new model class for the module.
An optional method could also be added to modules to support registering automation tasks, but several changes to the core would be necessary to support it. The potential backward-incompatiblities typically stem from the design changes that would be necessary to provide the module access to additional data like an instance of the Record object.
Whatever we do we need to maintain backwards compatibility. Allowing the module to register an automation task would be most flexible as Blesta would handle the scheduling automatically and the frequency or time the tasks run would be configurable in the standard place.
If database access cannot be granted without introducing a backwards incompatible change, perhaps a method in the core could be provided that allows the module to search/select/update related services. Maybe we don't want services to be able to perform any query under the sun, which could prove dangerous. 
This sounds like a difficult task to integrate. Modules will need database access, similar to plugins, and this will probably change module design requirements and make them backward-incompatible with the current design. This also raises the question of the difference between modules and plugins and would likely lead to other refactoring.
This task may also be dependent on cron task refactoring in CORE-2518.