Details
-
Type:
Improvement
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 4.0.0
-
Fix Version/s: Sponsored
-
Component/s: None
-
Labels:None
Description
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system.
We should log everything we can about services here, similar to the log_contacts table which tracks every change for clients and contacts. We can add a new column log_services.change (modeled after log_contacts), that logs everything that changes with a service. log_services.status could remain an indicator of the current status of the service when the change is logged.
What do we log?
- Any status changes. Service Created. Service transitioning from Pending to Active, or Active to Suspended, Suspended to Cancelled, etc.
- Any change to service meta data. For example, domain is changed from mydomain.com to yourdomain.com
- Any change to a configurable option, such as disk 10GB changed to 20GB (Config option upgrades/downgrades)
- Any upgrade/downgrades of associated Package.
Like log_contacts, only log items that have changed. We may wish to log all data when a service is created, however.
This service log should be associated with the service for which it belongs. Add a new tab "Log" when managing a service as an admin only. This tab will show a log of all changes (Click row to expand and show details), similar to the contact log.
Activity
Paul Phillips
created issue -
| Field | Original Value | New Value |
|---|---|---|
| Rank | Ranked lower |
| Rank | Ranked higher |
| Fix Version/s | Sponsored [ 11113 ] | |
| Fix Version/s | Short Term [ 10800 ] |
Paul Phillips
made changes -
| Assignee | Tyson Phillips [ tyson ] |
Paul Phillips
made changes -
| Description |
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system. We should also be logging when services are cancelled, scheduled to be cancelled, or unscheduled to be cancelled and the staff member responsible. Would log_services be the right place for this? |
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system. We should log everything we can about services here, similar to the log_contacts table which tracks every change for clients and contacts. We can add a new column log_services.change (modeled after log_contacts), that logs everything that changes with a service. log_services.status could remain an indicator of the current status of the service when the change is logged. What do we log? * Any status changes. Service Created. Service transitioning from Pending to Active, or Active to Suspended, Suspended to Cancelled, etc. * Any change to service meta data. For example, domain is changed from mydomain.com to yourdomain.com * Any change to a configurable option, such as disk 10GB changed to 20GB Like log_contacts, only log items that have changed. We may wish to log all data when a service is created, however. This service log should be associated with the service for which it belongs. |
Paul Phillips
made changes -
| Description |
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system. We should log everything we can about services here, similar to the log_contacts table which tracks every change for clients and contacts. We can add a new column log_services.change (modeled after log_contacts), that logs everything that changes with a service. log_services.status could remain an indicator of the current status of the service when the change is logged. What do we log? * Any status changes. Service Created. Service transitioning from Pending to Active, or Active to Suspended, Suspended to Cancelled, etc. * Any change to service meta data. For example, domain is changed from mydomain.com to yourdomain.com * Any change to a configurable option, such as disk 10GB changed to 20GB Like log_contacts, only log items that have changed. We may wish to log all data when a service is created, however. This service log should be associated with the service for which it belongs. |
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system. We should log everything we can about services here, similar to the log_contacts table which tracks every change for clients and contacts. We can add a new column log_services.change (modeled after log_contacts), that logs everything that changes with a service. log_services.status could remain an indicator of the current status of the service when the change is logged. What do we log? * Any status changes. Service Created. Service transitioning from Pending to Active, or Active to Suspended, Suspended to Cancelled, etc. * Any change to service meta data. For example, domain is changed from mydomain.com to yourdomain.com * Any change to a configurable option, such as disk 10GB changed to 20GB Like log_contacts, only log items that have changed. We may wish to log all data when a service is created, however. This service log should be associated with the service for which it belongs. Add a new tab "Log" when managing a service as an admin only. This tab will show a log of all changes (Click row to expand and show details), similar to the contact log. |
Paul Phillips
made changes -
| Description |
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system. We should log everything we can about services here, similar to the log_contacts table which tracks every change for clients and contacts. We can add a new column log_services.change (modeled after log_contacts), that logs everything that changes with a service. log_services.status could remain an indicator of the current status of the service when the change is logged. What do we log? * Any status changes. Service Created. Service transitioning from Pending to Active, or Active to Suspended, Suspended to Cancelled, etc. * Any change to service meta data. For example, domain is changed from mydomain.com to yourdomain.com * Any change to a configurable option, such as disk 10GB changed to 20GB Like log_contacts, only log items that have changed. We may wish to log all data when a service is created, however. This service log should be associated with the service for which it belongs. Add a new tab "Log" when managing a service as an admin only. This tab will show a log of all changes (Click row to expand and show details), similar to the contact log. |
We have a table called log_services, where we log service status changes of the type suspend and unsuspend, along with the service ID, and staff member that performed the action (if any).
I believe the original intent of the log_services table was to prevent services that were suspended by a staff member from being unsuspended by the system. We should log everything we can about services here, similar to the log_contacts table which tracks every change for clients and contacts. We can add a new column log_services.change (modeled after log_contacts), that logs everything that changes with a service. log_services.status could remain an indicator of the current status of the service when the change is logged. What do we log? * Any status changes. Service Created. Service transitioning from Pending to Active, or Active to Suspended, Suspended to Cancelled, etc. * Any change to service meta data. For example, domain is changed from mydomain.com to yourdomain.com * Any change to a configurable option, such as disk 10GB changed to 20GB (Config option upgrades/downgrades) * Any upgrade/downgrades of associated Package. Like log_contacts, only log items that have changed. We may wish to log all data when a service is created, however. This service log should be associated with the service for which it belongs. Add a new tab "Log" when managing a service as an admin only. This tab will show a log of all changes (Click row to expand and show details), similar to the contact log. |