Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-2435

Allow modules to create their own automation tasks

    Details

    • Type: Story
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.0.0
    • Fix Version/s: 4.3.0-b1
    • Component/s: None
    • Labels:
      None

      Description

      1. 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?
      2. Add a new core cron task to call the automation method on all installed modules

      Things to consider:

      1. Modules are much similar to plugins now, and differentiating them while merging similar features may require refactoring (something to do in a major release)
      2. Modules need database access. Loading the Record component may not suffice, and an instance of it may need to be provided instead
      3. Logging mechanisms may need to be provided to the module and its automation task
      4. Backward compatibility must be maintained
      5. 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:

      1. Update Modules to support a new method, cron($key), similar to plugins. Default to do nothing
      2. 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`)
      3. 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)
      4. 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

      See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670

        Activity

        Automated transition triggered when Tyson Phillips (Inactive) merged pull request #415 in Stash -
        Status In Review [ 5 ] Closed [ 6 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 day, 51 minutes [ 31860 ] 1 day, 1 hour, 1 minute [ 32460 ]
        Worklog Id 10970 [ 10970 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.3.0 Sprint 5, 4.3.0 Sprint 6 [ 55, 56 ] 4.3.0 Sprint 5, 4.3.0 Sprint 6, 4.3.0 Sprint 7 [ 55, 56, 57 ]
        tyson Tyson Phillips (Inactive) made changes -
        Time Spent 1 day, 26 minutes [ 30360 ] 1 day, 51 minutes [ 31860 ]
        Worklog Id 10944 [ 10944 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 7 hours, 18 minutes [ 26280 ] 1 day, 26 minutes [ 30360 ]
        Worklog Id 10943 [ 10943 ]
        tyson Tyson Phillips (Inactive) made changes -
        Status Reopened [ 4 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        tyson Tyson Phillips (Inactive) made changes -
        Resolution Fixed [ 1 ]
        Status In Review [ 5 ] Reopened [ 4 ]
        Automated transition triggered when Tyson Phillips (Inactive) created pull request #415 in Stash -
        Status In Progress [ 3 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        tyson Tyson Phillips (Inactive) made changes -
        Epic Link CORE-2643 [ 13800 ]
        tyson Tyson Phillips (Inactive) made changes -
        Time Spent 2 hours, 2 minutes [ 7320 ] 7 hours, 18 minutes [ 26280 ]
        Worklog Id 10936 [ 10936 ]
        Automated transition triggered when Tyson Phillips (Inactive) created a branch in Stash -
        Status Open [ 1 ] In Progress [ 3 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.3.0 Sprint 5 [ 55 ] 4.3.0 Sprint 5, 4.3.0 Sprint 6 [ 55, 56 ]
        tyson Tyson Phillips (Inactive) made changes -
        Time Spent 1 hour, 58 minutes [ 7080 ] 2 hours, 2 minutes [ 7320 ]
        Worklog Id 10835 [ 10835 ]
        tyson Tyson Phillips (Inactive) made changes -
        Issue Type New Feature [ 2 ] Story [ 7 ]
        tyson Tyson Phillips (Inactive) made changes -
        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)

        ----

        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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        # 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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        tyson Tyson Phillips (Inactive) made changes -
        Time Spent 41 minutes [ 2460 ] 1 hour, 58 minutes [ 7080 ]
        Worklog Id 10834 [ 10834 ]
        tyson Tyson Phillips (Inactive) made changes -
        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.
        #* Update existing CronTasks methods and queries that use 'plugin_dir' to continue to work as before
        #* Add any new methods necessary to implement the same functionality on the new structure. Deprecate existing methods accordingly
        #* Update all core system calls to CronTasks to use the new methods
        #* (Create new tasks for each core plugin that uses cron tasks to update them accordingly)

        ----

        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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        # 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)

        ----

        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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        tyson Tyson Phillips (Inactive) made changes -
        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

        ----

        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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        # 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.
        #* Update existing CronTasks methods and queries that use 'plugin_dir' to continue to work as before
        #* Add any new methods necessary to implement the same functionality on the new structure. Deprecate existing methods accordingly
        #* Update all core system calls to CronTasks to use the new methods
        #* (Create new tasks for each core plugin that uses cron tasks to update them accordingly)

        ----

        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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        tyson Tyson Phillips (Inactive) made changes -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 41 minutes [ 2460 ]
        Worklog Id 10833 [ 10833 ]
        tyson Tyson Phillips (Inactive) made changes -
        Fix Version/s 4.3.0-b1 [ 11019 ]
        Fix Version/s 4.3.0 [ 11022 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.3.0 Sprint 5 [ 55 ]
        tyson Tyson Phillips (Inactive) made changes -
        Story Points 8
        tyson Tyson Phillips (Inactive) made changes -
        Assignee Tyson Phillips [ tyson ]
        tyson Tyson Phillips (Inactive) made changes -
        Fix Version/s 4.3.0 [ 11022 ]
        Fix Version/s Short Term [ 10800 ]
        tyson Tyson Phillips (Inactive) made changes -
        Description 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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        # 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

        ----

        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

        See https://www.blesta.com/forums/index.php?/topic/4032-allow-modules-to-add-cron-tasks/&tab=comments#comment-54670
        tyson Tyson Phillips (Inactive) made changes -
        Field Original Value New Value
        Rank Ranked higher
        admin Paul Phillips created issue -

          People

          • Assignee:
            tyson Tyson Phillips (Inactive)
            Reporter:
            admin Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              15/Jun/18

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 day, 5 hours, 40 minutes
              1d 5h 40m

                Agile