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
Field | Original Value | New Value |
---|---|---|
Rank | Ranked higher |
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. |
Story Points | 5 |
Rank | Ranked higher |
Sprint | 4.2.0 Sprint 3 [ 48 ] |
Rank | Ranked higher |
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. |
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. |
Issue Type | Improvement [ 4 ] | Story [ 7 ] |
Fix Version/s | 4.2.0-b1 [ 11014 ] |
Remaining Estimate | 0 minutes [ 0 ] | |
Time Spent | 20 minutes [ 1200 ] | |
Worklog Id | 10437 [ 10437 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Time Spent | 20 minutes [ 1200 ] | 2 hours, 3 minutes [ 7380 ] |
Worklog Id | 10445 [ 10445 ] |
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 ] |
Status | In Progress [ 3 ] | Closed [ 6 ] |
Resolution | Fixed [ 1 ] |