Story #2068

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.

Added by Tom Clegg almost 7 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
-
Start date:
03/27/2014
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
1.0
Release relationship:
Auto

Description

  • 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.

Subtasks

Task #2482: Review code updates in branch 2068-reset-userResolvedRadhika Chippada

Task #2481: Invoke the API server's unsetup method from workbench when an admin user clicks on the "Deactivate" button from the user's Admin tab.ResolvedRadhika Chippada

Task #2480: Add functional tests for the unsetup method from the API serverResolvedRadhika Chippada

Task #2479: Expose "unsetup" method from the API serverResolvedRadhika Chippada

History

#1 Updated by Tom Clegg over 6 years ago

  • Description updated (diff)
  • Target version set to 2014-04-16 Dev tools and data/resource management
  • Story points changed from 2.0 to 1.0

#2 Updated by Tim Pierce over 6 years ago

  • Assigned To set to Tim Pierce

#3 Updated by Tim Pierce over 6 years ago

  • Assigned To changed from Tim Pierce to Radhika Chippada

#4 Updated by Tom Clegg over 6 years ago

  • Description updated (diff)
Notes
  • 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.
    • Use 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"

#5 Updated by Radhika Chippada over 6 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF