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

        There are no Sub-Tasks for this issue.

          Activity

          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.

            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