Currently, any user can go to the dashboard menu and choose to "Re-Deploy" to another disaster. What this does now is emails to an admin a request to the admin of the organization and the new disaster they want access to. An admin would manually log in, pull up the org, and go choose the event that the user requested on behalf of the organization.
This task slightly changes that process. The email can sill go out as a backup or notification. The change is that we want to go ahead and store the request somehow so that it shows up in the search grid as defined in issue #368 and when you hit Approve Redeploy it is permanent, and if you hit Reject Redeploy, it kicks out the request and everything is normal again.
In either case, a time-stamped note including the name of the person doing the accepting or rejecting is appended to the Admin Notes.
Currently, any user can go to the dashboard menu and choose to "Re-Deploy" to another disaster. What this does now is emails to an admin a request to the admin of the organization and the new disaster they want access to. An admin would manually log in, pull up the org, and go choose the event that the user requested on behalf of the organization.
This task slightly changes that process. The email can sill go out as a backup or notification. The change is that we want to go ahead and store the request somehow so that it shows up in the search grid as defined in issue #368 and when you hit Approve Redeploy it is permanent, and if you hit Reject Redeploy, it kicks out the request and everything is normal again.
In either case, a time-stamped note including the name of the person doing the accepting or rejecting is appended to the Admin Notes.