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
Activity
Tyson Phillips (Inactive)
created issue -
Tyson Phillips (Inactive)
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Rank | Ranked higher |
Tyson Phillips (Inactive)
made changes -
Tyson Phillips (Inactive)
made changes -
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 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 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 Phillips (Inactive)
made changes -
| Story Points | 5 |
Tyson Phillips (Inactive)
made changes -
| Rank | Ranked higher |
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 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 Phillips (Inactive)
made changes -
| Sprint | 4.2.0 Sprint 3 [ 48 ] |
Tyson Phillips (Inactive)
made changes -
| Rank | Ranked higher |
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 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 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 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 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 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 Phillips (Inactive)
made changes -
| Issue Type | Improvement [ 4 ] | Story [ 7 ] |
Tyson Phillips (Inactive)
made changes -
| Fix Version/s | 4.2.0-b1 [ 11014 ] |
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 Phillips (Inactive)
made changes -
| Time Spent | 20 minutes [ 1200 ] | 2 hours, 3 minutes [ 7380 ] |
| Worklog Id | 10445 [ 10445 ] |
Tyson Phillips (Inactive)
made changes -
| Time Spent | 2 hours, 3 minutes [ 7380 ] | 2 hours, 36 minutes [ 9360 ] |
| Worklog Id | 10447 [ 10447 ] |
| Time Spent | 2 hours, 36 minutes [ 9360 ] | 3 hours, 27 minutes [ 12420 ] |
| Worklog Id | 10498 [ 10498 ] |
| Time Spent | 3 hours, 27 minutes [ 12420 ] | 4 hours, 2 minutes [ 14520 ] |
| Worklog Id | 10519 [ 10519 ] |
Tyson Phillips (Inactive)
made changes -
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
"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?