Feature #4951

[Workbench] When a user does not have access to a VM, provide a way to contact the site admin to request access.

Added by Peter Amstutz over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
Workbench
Target version:
Start date:
02/05/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
1.0

Description

For security reasons, auto-activated users are not granted access to VMs by default. This is confusing since the tutorials are mostly written on the assumption that you are logged into a VM.

When the user does not have access to a VM, the "Manage account" page should have a noticeable alert to this effect ("Many Arvados features depend on having shell access to a hosted VM, but this hasn't been set up for your account yet."), and a button "Request shell access". These should go in the 'Virtual Machines' section where the VMs would be listed normally. (If there are any VMs the user has access to, the alert and the button should not appear.)

When clicked, an e-mail is sent to the site-configured admin email address, with subject "Shell account request from Full Name (email, qr1hi-tpzed-useruuid)". The body of the e-mail should contain the user's particulars (name and institutional e-mail address) and a link to the Admin tab of the "show user" page where the VM request can be granted.

When the user clicks the button, it should disable and change its text to "Requesting..." while the request is in progress. remote:true,data:{disable_with:'Requesting...'} -- see Rails docs.

If there's time...

When the AJAX request completes and the email has been sent to the admin,
  • the button should go back to normal.
  • a div.alert-info should appear near the button saying "Shell account requested."
  • set a flag in html5 local storage to remember this state.
  • next time the page is displayed, if there is still no VM access, check html5 local storage and show the div.alert-info if appropriate. (This is imperfect because it won't remember state across browsers/computers, but that's OK.)

If there isn't time...

When the AJAX request completes, show an alert box (either alert() or div.alert) confirming the request has been sent, and put the button text back to normal.

disabled-send-request-button.png (149 KB) disabled-send-request-button.png Peter Amstutz, 02/11/2015 09:34 PM

Subtasks

Task #5144: Review branch: 4951-request-vmResolvedRadhika Chippada

Associated revisions

Revision 26ac1b2f
Added by Radhika Chippada over 5 years ago

closes #4951
Merge branch '4951-request-vm'

Revision ff3e4c60
Added by Tom Clegg over 5 years ago

Merge branch '4951-request-vm-TC' refs #4951

History

#1 Updated by Peter Amstutz over 5 years ago

  • Description updated (diff)

#2 Updated by Tom Clegg over 5 years ago

  • Target version changed from Bug Triage to 2015-02-18 sprint

#3 Updated by Ward Vandewege over 5 years ago

  • Description updated (diff)

#4 Updated by Ward Vandewege over 5 years ago

  • Story points set to 0.5

#5 Updated by Tom Clegg over 5 years ago

  • Description updated (diff)
  • Category set to Workbench

#6 Updated by Radhika Chippada over 5 years ago

  • Assigned To set to Radhika Chippada
  • Story points changed from 0.5 to 1.0

#7 Updated by Radhika Chippada over 5 years ago

  • Status changed from New to In Progress

#8 Updated by Peter Amstutz over 5 years ago

In workbench routes.rb:

 get '/manage_account' => 'users#manage_account'
 get '/manage_acct' => 'users#manage_account', :as => :manage_acct

What is the purpose of the /manage_acct route? It seems like it is just an (unnecessary) alias for /manage/account?

If I hit "Request VM access" and then hit "reload", I get the "Request VM access" button again instead of the notification box indicating that a request was sent.

On further review, it appears that the difference between /manage_acct and /manage/account is whether the "Request VM" button is rendered or not? This seems like a misguided way to indicate state when a query parameter might be more appropriate (?requestedVM=true).

If you're going to use local storage, you should be using a javascript fragment on the manage account to update the page according to the local state, rather than this indirect route of using javascript to send the user to a different URL entirely.

However, storing this flag in local state seems like entirely the wrong way to do this. Why not store the "VM requested" as a row in the links table? Then the manage account page can query for the "requested" link and decide how to render it that way. (I know the answer is "because the description says so" but we should talk to Tom).

#9 Updated by Radhika Chippada over 5 years ago

Peter, thanks for your suggestion. I now moved the logic to show / hide the request access button using jQuery ready function. This has simplified the code significantly and I no longer needed the additional route. Thanks.

#10 Updated by Peter Amstutz over 5 years ago

  • What's the purpose of wrapping localStorage.getItem(item) and localStorage.removeItem(item) with getLocalStorageValue() and clearLocalStorageValue() ? This seems like an unnecessary obfuscation.
  • Suggestions for text changes:
    • "Many of the Arvados features depend on having shell access to a hosted VM." -> "Some Arvados features require using the command line. You may request access to a hosted virtual machine with a command line shell."
    • "Request shell access" -> "Send request for shell access"
    • "A request was sent on your behalf" -> "A request for access was sent on at 1/23/45 at 1:02:03"

#11 Updated by Peter Amstutz over 5 years ago

After I click "Send request for shell access" and then reload the page, the "Send request for shell access" button is disabled. I don't know if that is intentional. My intention in suggesting that it stay on the page is to allow the user to send another request if they feel like their initial request was ignored.

Everything else looks good.

#12 Updated by Peter Amstutz over 5 years ago

I can't click on the button either.

#13 Updated by Peter Amstutz over 5 years ago

Here's the HTML for the button. I suspect Firefox is interpreting disabled="" as disabled.

<input disabled="" class="btn btn-xs btn-primary" id="request_shell_submit" value="Send request for shell access" type="submit">

#15 Updated by Radhika Chippada over 5 years ago

  • Status changed from In Progress to Resolved

Applied in changeset arvados|commit:26ac1b2f41916d1f4040073a15dfae5f1b294cb5.

#16 Updated by Tom Clegg over 5 years ago

Looking at 1de8e55

  • How/why does $.ajax('/') work? shouldn't that point to /users/request_shell_access?
  • Instead of $.ajax(...,success:function(){...}) on the page and {render nothing: true} in the handler, how about
    
    // manage_account page:
    <a data-remote="true" href="/users/request_shell_access">...</a>
    
    // app/views/users/request_shell_access.js:
    $('.no_shell_access').append('<div class="alert alert-success"><p class="contain-align-left">A request for shell access was sent.</p></div>');
    [...]
    

#17 Updated by Radhika Chippada over 5 years ago

  • I incorrectly used button_to (which cannot be used to submit without form_to) for the request button. It unfortunately worked with Firefox making it slip. I now updated the request button to link_to. The submission now works with Chrome as well. Also, the test now actually results in sending an email.
  • Updated the integration test to also verfiy the email message.
  • Updated the js as suggested by Tom.

Also available in: Atom PDF