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

Validate service changes before queuing them

    Details

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

      Description

      I think Module::validateService($package, array $vars = null) will need to have a sister method, Module::validateServiceEdit(stdClass $service, array $vars = []) to validate data when a service is to be edited.

      Anywhere we call a module's validateService method to validate an EDIT we should call validateServiceEdit instead.

      Modules can be updated to implement the new validateServiceEdit method-and they should-for service's being edited. validateService is only for validating data for the creation of a service. We should update all of the core modules for this purpose.

      When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).


      I think Module::validateService($package, array $vars = null) will need to be updated to accept a third argument: $edit = false.

      Anywhere we call a module's validateService method, we should pass the third argument of whether we want to validate for a service being added (default) or edited. In some cases, modules themselves may need to be updated to differentiate between validating for adding/editing, but that need only be checked for modules that set their own custom third argument for that method anyway.

      When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).


      When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

      However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

      It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

      A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

      There would need to be a method by which to validate a service and its module before an attempt to edit it is made.

        Issue Links

        1.
        Update module system to support validating service updates Sub-task Closed Tyson Phillips (Inactive)

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 20 minutes
         
        2.
        Update service changes to be validated prior to being queued Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 2 hours, 9 minutes
         
        3.
        BuycPanel: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 26 minutes
         
        4.
        CentovaCast: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 5 minutes
         
        5.
        cPanel: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 13 minutes
         
        6.
        DirectAdmin: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        58%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 10 minutes Remaining Estimate - 7 minutes
         
        7.
        GoGetSSL: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 15 minutes
         
        8.
        Interworx: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 1 hour, 12 minutes
         
        9.
        Multicraft: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 45 minutes
         
        10.
        NameCheap: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 47 minutes
         
        11.
        Plesk: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 27 minutes
         
        12.
        Proxmox: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 24 minutes
         
        13.
        SolusVM: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 52 minutes
         
        14.
        TcAdmin: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 22 minutes
         
        15.
        Universal Module: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 20 minutes
         
        16.
        Vesta: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 10 minutes
         
        17.
        Virtualmin: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 9 minutes
         
        18.
        VPS.NET: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 31 minutes
         
        19.
        WHMSonic: Add support for validating service edits Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 29 minutes
         
        20.
        TastycPanel: Add support for validating service edits (github) Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 53 minutes
         
        21.
        TastyInterworx: Add support for validating service edits (github) Sub-task Closed Jonathan Reissmueller

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 54 minutes
         

          Activity

          tyson Tyson Phillips (Inactive) created issue -
          tyson Tyson Phillips (Inactive) made changes -
          Field Original Value New Value
          Rank Ranked higher
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-1634 [ CORE-1634 ]
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-1767 [ CORE-1767 ]
          tyson Tyson Phillips (Inactive) made changes -
          Description When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

          However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

          It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

          A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

          There would need to be a method by which to validate a service and its module before an attempt to edit it is made.
          I think Module::validateService($package, array $vars = null) will need to be updated to accept a third argument: $edit = false.

          Anywhere we call a module's validateService method, we should pass the third argument of whether we want to validate for a service being added (default) or edited. In same cases, modules themselves may need to be updated to differentiate between validating for adding/editing, but that need only be checked for modules that set their own custom third argument for that method anyway.

          When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).

          ----

          When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

          However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

          It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

          A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

          There would need to be a method by which to validate a service and its module before an attempt to edit it is made.
          tyson Tyson Phillips (Inactive) made changes -
          Story Points 5
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked higher
          Hide
          admin Paul Phillips added a comment -

          "if i'm reading the task right it'd allow us to block an upgrade/downgrade if say a smaller package would result in an exceeded threshold" yes/no?

          Show
          admin Paul Phillips added a comment - "if i'm reading the task right it'd allow us to block an upgrade/downgrade if say a smaller package would result in an exceeded threshold" yes/no?
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          I'm not sure what you mean by that. This task aims to perform rule validation on service changes when the system is setup to queue service changes. Queued service changes are currently not validated when they are queued. They are validated when the service is edited, which occurs when the queued service change is processed by cron.

          Non-queued service changes are validated immediately since the service is attempted to be updated immediately. Rule validation occurs and any errors encountered are shown in the UI.

          Queued service changes are saved to be changed later by cron. When the cron runs, it attempts to edit the service based on the service changes. Rule validation occurs and errors encountered are not seen. The service change fails and is never processed again due to the failure.

          Show
          tyson Tyson Phillips (Inactive) added a comment - I'm not sure what you mean by that. This task aims to perform rule validation on service changes when the system is setup to queue service changes. Queued service changes are currently not validated when they are queued. They are validated when the service is edited, which occurs when the queued service change is processed by cron. Non-queued service changes are validated immediately since the service is attempted to be updated immediately. Rule validation occurs and any errors encountered are shown in the UI. Queued service changes are saved to be changed later by cron. When the cron runs, it attempts to edit the service based on the service changes. Rule validation occurs and errors encountered are not seen. The service change fails and is never processed again due to the failure.
          tyson Tyson Phillips (Inactive) made changes -
          Sprint 4.2.0 Sprint 3 [ 48 ]
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked higher
          tyson Tyson Phillips (Inactive) made changes -
          Description I think Module::validateService($package, array $vars = null) will need to be updated to accept a third argument: $edit = false.

          Anywhere we call a module's validateService method, we should pass the third argument of whether we want to validate for a service being added (default) or edited. In same cases, modules themselves may need to be updated to differentiate between validating for adding/editing, but that need only be checked for modules that set their own custom third argument for that method anyway.

          When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).

          ----

          When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

          However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

          It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

          A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

          There would need to be a method by which to validate a service and its module before an attempt to edit it is made.
          I think Module::validateService($package, array $vars = null) will need to -be updated to accept a third argument: $edit = false.- have a sister method, Module::validateServiceEdit(($package/$service))

          Anywhere we call a module's validateService method, we should pass the third argument of whether we want to validate for a service being added (default) or edited. In same cases, modules themselves may need to be updated to differentiate between validating for adding/editing, but that need only be checked for modules that set their own custom third argument for that method anyway.

          When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).

          ----

          When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

          However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

          It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

          A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

          There would need to be a method by which to validate a service and its module before an attempt to edit it is made.
          tyson Tyson Phillips (Inactive) made changes -
          Description I think Module::validateService($package, array $vars = null) will need to -be updated to accept a third argument: $edit = false.- have a sister method, Module::validateServiceEdit(($package/$service))

          Anywhere we call a module's validateService method, we should pass the third argument of whether we want to validate for a service being added (default) or edited. In same cases, modules themselves may need to be updated to differentiate between validating for adding/editing, but that need only be checked for modules that set their own custom third argument for that method anyway.

          When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).

          ----

          When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

          However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

          It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

          A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

          There would need to be a method by which to validate a service and its module before an attempt to edit it is made.
          I think Module::validateService($package, array $vars = null) will need to have a sister method, *Module::validateServiceEdit(stdClass $service, array $vars = [])* to validate data when a service is to be edited.

          Anywhere we call a module's _validateService_ method to validate an EDIT we should call _validateServiceEdit_ instead.

          Modules can be updated to implement the new _validateServiceEdit_ method--and they should--for service's being edited. _validateService_ is only for validating data for the creation of a service. We should update all of the core modules for this purpose.

          When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).

          ----

          I think Module::validateService($package, array $vars = null) will need to be updated to accept a third argument: $edit = false.

          Anywhere we call a module's validateService method, we should pass the third argument of whether we want to validate for a service being added (default) or edited. In some cases, modules themselves may need to be updated to differentiate between validating for adding/editing, but that need only be checked for modules that set their own custom third argument for that method anyway.

          When a queued service change occurs, we should validate the service and the service's module before queuing the service. This should help alleviate some issues with services failing to be provisioned because of invalid data. Subsequent steps would be to handle errored/failed service changes better (e.g. send an email for those that fail).

          ----

          When managing a service as a client or an admin, the service changes can be queued. This feature was added to queue service changes until an invoice is paid as apart of CORE-1634.

          However, if queuing is enabled, no validation takes place against the selected service fields before they are queued. If input data queued is invalid, it will not be known until an error is generated by the cron when attempting to process the changes.

          It is currently not possible to accurately validate service changes before they are queued. This is because the module performs no validation on service fields until the module's addService() or editService() methods are called. i.e. validation currently only takes place at the time the service is being updated.

          A module's validateService() method does not differentiate between whether the data being validated is for a new service (being added) or an existing service (being edited), so that cannot be used either. Similarly for Services::validate and Services::validateService.

          There would need to be a method by which to validate a service and its module before an attempt to edit it is made.
          tyson Tyson Phillips (Inactive) made changes -
          Issue Type Improvement [ 4 ] Story [ 7 ]
          tyson Tyson Phillips (Inactive) made changes -
          Fix Version/s 4.2.0-b1 [ 11014 ]
          tyson Tyson Phillips (Inactive) made changes -
          Remaining Estimate 0 minutes [ 0 ]
          Time Spent 20 minutes [ 1200 ]
          Worklog Id 10437 [ 10437 ]
          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 20 minutes [ 1200 ] 2 hours, 3 minutes [ 7380 ]
          Worklog Id 10445 [ 10445 ]
          tyson Tyson Phillips (Inactive) made changes -
          Time Spent 2 hours, 3 minutes [ 7380 ] 2 hours, 36 minutes [ 9360 ]
          Worklog Id 10447 [ 10447 ]
          jonathan Jonathan Reissmueller made changes -
          Time Spent 2 hours, 36 minutes [ 9360 ] 3 hours, 27 minutes [ 12420 ]
          Worklog Id 10498 [ 10498 ]
          jonathan Jonathan Reissmueller made changes -
          Time Spent 3 hours, 27 minutes [ 12420 ] 4 hours, 2 minutes [ 14520 ]
          Worklog Id 10519 [ 10519 ]
          tyson Tyson Phillips (Inactive) made changes -
          Status In Progress [ 3 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                5/Dec/17

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Time Spent - 1 day, 7 hours, 55 minutes Remaining Estimate - 7 minutes
                7m
                Logged:
                Time Spent - 1 day, 7 hours, 55 minutes Remaining Estimate - 7 minutes
                1d 7h 55m

                  Agile