Arvados

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

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.

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

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.

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">

May be https://stackoverflow.com/questions/5985839/bug-with-firefox-disabled-attribute-of-input-not-resetting-when-refreshing

Will let it go. LGTM, please merge.

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>');
  [...]
  

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