Administrator can quickly reset a test user account to the "new, inactive, not invited" state with no repository/VM access, and log in to Workbench as that user, in order to efficiently test new user UI/API behavior and activation scripts.
(Total: 0.00 h)
- If logged in as admin, "De-activate" button + explanation appears on the Admin tab of Users→show.
- Admin must confirm with a browser alert box.
- API server "unsetup" API:
- Remove all repository and VM permission(s).
- Remove user agreement signature(s).
- Remove can_login links with email addresses.
- Set user is_active flag to false.
#4 Updated by Tom Clegg over 6 years ago
- Description updated (diff)
- Workbench unsetup route should be put (or post?), not get
- Text on the workbench page should say "Deactivate and reset" (or "un-setup"?) and explain what the consequences will be ("This will remove all repository/VM permissions; if you "setup" the user again, the user will have to sign the user agreement again", etc)
- Button style: should just need to add
class: 'btn btn-primary'to the html options on the link
- Might be better to say button_to instead of link_to (as long as it uses the right http method I don't suppose this matters much - but button_to might make it easier to convince Rails to put/post)
- In workbench User.unsetup, don't take a "user" argument -- just operate on self.
- In workbench User.unsetup, instead of returning a new hash with the updated fields, call private_reload(...unpack...(res)) and then return self. (That way the caller can just say "@object.unsetup" instead of "@object = @object.unsetup".)
- In api server, use the before_filters to deal with the admin, lookup, 404 logic for you.
- Don't skip the find_object_by_uuid and render_404_if_no_object filters.
before_filter :admin_required, only: [:setup, :unsetup](we forgot to use this in setup!)
- Then the unsetup action reduces to just "@object.unsetup" and "show"