Details
-
Type:
New Feature
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.5.0
-
Fix Version/s: None
-
Component/s: Staff Interface
-
Labels:None
Description
It's sometimes necessary to re-provision a service through the module that's already active in Blesta.
Staff, from the client profile, possibly under Service > Manage > Actions should be able to re-provision a service using the module. If added here, the "Use module" option should be checked and disabled. It may make sense to instead have a new tab called "Commands" or similar to allow module commands to be executed devoid of any action in Blesta including "Create", "Cancel", "Suspend", and "Unsuspend".
Performing the action would attempt to provision the service as if the service were paid pending and the cron ran, or, if the service were added manually by staff with "Use module" selected.
This may produce errors if the service already exists via the module, or if the service is lacking the necessary information to provision. In the latter case, I believe the module would be the cause for any lack of information depending on how it manipulates the data during the original creation of the service. This is beyond our control.
Alternatively it may be desirable to be able to set the service back to "Pending", and allow the cron to attempt to re-provision.
Activity
Yes, that may be the best course of action in many cases. However, doing so would change the start date and billing cycle for the service, require re-entering a lot of data that may not be readily apparent, and several more steps to get everything back where it should be. Time wasted if the module will work with this method.
Knowledgeable staff should still be able to perform advanced functions like this. If it doesn't work as expected, or they know the module will not properly handle the action, they can take the longer route.
I think an advanced "Commands" tab as mentioned in the task description is really the best solution here, which would support the 4 module commands (Create, Suspend, Unsuspend, Cancel) which would not affect the local service. Perhaps access to this can be limited by Staff ACL.
As it is currently, you can make service changes locally without using the module (uncheck "Use Module"), this would simply allow the inverse.
Paul Phillips
added a comment - Yes, that may be the best course of action in many cases. However, doing so would change the start date and billing cycle for the service, require re-entering a lot of data that may not be readily apparent, and several more steps to get everything back where it should be. Time wasted if the module will work with this method.
Knowledgeable staff should still be able to perform advanced functions like this. If it doesn't work as expected, or they know the module will not properly handle the action, they can take the longer route.
I think an advanced "Commands" tab as mentioned in the task description is really the best solution here, which would support the 4 module commands (Create, Suspend, Unsuspend, Cancel) which would not affect the local service. Perhaps access to this can be limited by Staff ACL.
As it is currently, you can make service changes locally without using the module (uncheck "Use Module"), this would simply allow the inverse. Why can't we just automate the cancel and re-add process? User sees a screen that contains all of the Add service fields prefilled with what we can prefill from the existing service, then they submit, we error check, service is added, previously service is canceled, service dates are updated if necessary.
I can't see a way that modules could support reprovisioning a service that has already been provisioned. The data simply isn't there anymore.
Cody Phillips (Inactive)
added a comment - Why can't we just automate the cancel and re-add process? User sees a screen that contains all of the Add service fields prefilled with what we can prefill from the existing service, then they submit, we error check, service is added, previously service is canceled, service dates are updated if necessary.
I can't see a way that modules could support reprovisioning a service that has already been provisioned. The data simply isn't there anymore. 
This has technical limitations. Since the currently stored service data is not necessarily the same as the original input data, it's not possible to submit to the module in many cases.
I think it would make more sense to simply cancel and recreate the service.