Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
It would be extremely valuable if the user had an option to report a problem with a reservation. It can often be difficult or impossible to troubleshoot a problem that a user reported because the reservation has timed out or was deleted by the user (very likely if the user only has access to 1 reservation at a time). As a result, the computer the user had a problem with has been reloaded and there is no way to diagnose.
The likely location would be under the More Options button. The user would select Report a Problem. He would then be presented with a pane where text could be entered along with some instructions. Contained in the instructions could be some info such as did you try the restart option?. There could also be some checkboxes with common problems:
- Unable to connect
- Unable to login with credentials provided
- Connection is slow
- I'm unable to extend my reservation but I really need it
- Other
These could be stored in something like a reservationproblemtype table so that they could be customized for different VCL deployments.
When the user submits the problem report, the request state would change to something like problem. This state would be similar to maintenance. The backend would under no circumstances reload the computer.
The problem report could also contain a checkbox allowing the user to specify whether or not the problem is terminal, meaning they can no longer use the reservation (can't connect, etc.). If this is true, the reservation would be frozen and they would be able to make another reservation without having to delete the problematic one. (This is something to think about, however, as it would be possible that a user who reached their concurrent reservation limit could abuse the feature. They could freeze a reservation and still connect to it. The backend wouldn't revoke access because doing so would diminish its usefulness in helping diagnose unable to connect problems.)
If not terminal, the reservation would remain and they would still have access to it and click the Connect button. The backend would continue to try to attempt to update the firewall if necessary but would never reload the computer. When the reservation end time is reached, the computer would not be reloaded.
Problematic reservations would appear on the Dashboard page similar to the failed image reservations.
There could also be a configuration option allowing system administrators to specify an email address to forward failed reservation information to so they automatically get entered into a call tracking system. It would be useful to be able to customize the subject of the email message.