Details
Description
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing
- Never
- 1
- 2
- ...
- 30
In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log.
In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service -
{service.name}This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages.
For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning.
Issue Links
- relates to
-
CORE-901
Add service action backoff after failure
-
- Closed
-
Activity
If we do this task it would make at least part of CORE-901 unnecessary
| Story Points | 5 |
| Fix Version/s | Sponsored [ 11113 ] | |
| Fix Version/s | 4.7.1 [ 11126 ] |
| Description |
Sometimes services fail to provision, and will continue to do so until something is changed manually. To prevent attempts to provision these every 5 minutes until forever, we should add a setting "Stop Automatic Provisions After Attempts" or some such thing. Then we add a drop down of how many attempts to make before suspending automatic provisions for a service. Probably 1-30 or no limit.
In order to do this we will either need to create a new log table or adapt the current log_services table to support service provision failures. We also need to make sure that users know that provisioning has been suspended. Maybe an email to the admin? Another log page? A notice message on the user profile? |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name "Service Provisioning Halted" and the subject "Automatic Provisioning Halted for Service - {service.name}". This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
| Description |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name "Service Provisioning Halted" and the subject "Automatic Provisioning Halted for Service - {service.name}". This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service - {service.name}. This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
| Description |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service - {service.name}. This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service - {service.name} This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
| Rank | Ranked higher |
Tyson Phillips (Inactive)
made changes -
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked lower |
Instead of using log_services we should generalize service_invoices
This task will work similar to the service renewal queue. We'll rename Tools > Renewal Queue, so that it works for both new and renewing services, and we will show whether it's a new or renewing service in the queue.
Paul Phillips
added a comment - This task will work similar to the service renewal queue. We'll rename Tools > Renewal Queue, so that it works for both new and renewing services, and we will show whether it's a new or renewing service in the queue. Paul Phillips
made changes -
| Fix Version/s | 5.11.0-b1 [ 11908 ] |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked lower |
We also may want to do this sort of thing for suspension/unsuspension/cancellation and not just for service creation