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

        admin Paul Phillips created issue -
        Hide
        tyson Tyson Phillips (Inactive) 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.

        Show
        tyson Tyson Phillips (Inactive) 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.
        Hide
        admin 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?

        Show
        admin 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?
        Hide
        tyson 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.

        Show
        tyson 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.
        Hide
        admin 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.

        Show
        admin 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.
        tyson Tyson Phillips (Inactive) made changes -
        Field Original Value New Value
        Rank Ranked higher
        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 -
        Fix Version/s 4.3.0 [ 11022 ]
        Fix Version/s Short Term [ 10800 ]
        tyson Tyson Phillips (Inactive) made changes -
        Assignee Tyson Phillips [ tyson ]
        tyson Tyson Phillips (Inactive) made changes -
        Story Points 8
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.3.0 Sprint 5 [ 55 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        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 -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 41 minutes [ 2460 ]
        Worklog Id 10833 [ 10833 ]
        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 -
        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 -
        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. *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 -
        Issue Type New Feature [ 2 ] Story [ 7 ]
        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 -
        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 -
        Rank Ranked higher
        Automated transition triggered when Tyson Phillips (Inactive) created a branch in Stash -
        Status Open [ 1 ] In Progress [ 3 ]
        tyson Tyson Phillips (Inactive) made changes -
        Time Spent 2 hours, 2 minutes [ 7320 ] 7 hours, 18 minutes [ 26280 ]
        Worklog Id 10936 [ 10936 ]
        tyson Tyson Phillips (Inactive) made changes -
        Epic Link CORE-2643 [ 13800 ]
        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 -
        Resolution Fixed [ 1 ]
        Status In Review [ 5 ] Reopened [ 4 ]
        tyson Tyson Phillips (Inactive) made changes -
        Status Reopened [ 4 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        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 -
        Time Spent 1 day, 26 minutes [ 30360 ] 1 day, 51 minutes [ 31860 ]
        Worklog Id 10944 [ 10944 ]
        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 -
        Rank Ranked higher
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 day, 51 minutes [ 31860 ] 1 day, 1 hour, 1 minute [ 32460 ]
        Worklog Id 10970 [ 10970 ]
        Automated transition triggered when Tyson Phillips (Inactive) merged pull request #415 in Stash -
        Status In Review [ 5 ] Closed [ 6 ]

          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