Actions
Feature #2272
closed
Admin can run setup-new-user.rb equivalent with a nice form from workbench
Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
-
Target version:
Story points:
1.0
Description
- Indicate on each row of "users" list which users have "is_invited" flag set to false. (Assuming this is easy. Should it be a separate issue?)
- On User->Show->Admin tab, if the user is missing any of the setup pieces (repo, VM, "all users") then a "Set up..." button appears, with an explanation why (e.g., "This user does not have VM access").
- The "Set up..." button brings up a dialog box asking for details needed to set up
- Choose a VM to give access to (hopefully we can make all VMs appear in the drop-down box)
- Repository name text entry box ("this will also be used as VM login username")
- "OK" and "Cancel" buttons
- "OK" sends AJAX request
- If successful, reload the current page to bring it up to date
- If unsuccessful, display error message in dialog box (bootstrap "alert" widget)
- On the Users->List page, add a button "Set up new user" button
- Brings up the same dialog box, but with added field
- Email address text entry box (on paste/keyup event, check whether anyone in the existing user list already has that address; if so, display a warning label (bootstrap widget) under the input saying "email address already in use!")
- OpenID prefix (with a default, from workbench config)
- Bonus: On success, insert a row at the top of the list for the new user. (But just reloading the index page would be fine.)
- If user is already partially set up, the form should say so near the appropriate input, e.g., "User already has VM access, username@vmname - you can leave this selection empty"
- If one of the fields is left blank, skip that part (e.g., no VM selected -> don't add VM permission)
- Test dialog box / form behavior using Capybara
Updated by Ward Vandewege over 10 years ago
- Target version changed from 2014-04-16 Dev tools and data/resource management to 2014-03-26 Debt service and dev painkillers
Updated by Ward Vandewege over 10 years ago
- Subject changed from Admin can run setup-new-user.rb with a nice form from workbench to Admin can run setup-new-user.rb equivalent with a nice form from workbench
Updated by Tom Clegg over 10 years ago
- Target version changed from 2014-03-26 Debt service and dev painkillers to 2014-04-16 Dev tools and data/resource management
Updated by Tom Clegg over 10 years ago
I haven't had a chance to look at the code yet, but here are notes on the UI:
- Use modal-header and modal-footer classes for title & buttons, like example at http://getbootstrap.com/javascript/#modals
- Looks a bit odd while loading the dialog content. Perhaps at least put a min-height on the box so it's not just a slit, and ideally say "Loading..." somehow. (Dialog title?)
- If you open the dialog, fill in some form fields, cancel, then re-open, the previous form input values appear for a moment until the new dialog content is reloaded. Should probably be reset to blank instead.
- Above center would be OK but below center looks a bit odd. Is this because the dialog is centered before the content is loaded? If it's easier than centering it, something like top=1/4 window height would probably work.
- Get rid of vertical scroll bar
- Cancel button should be btn-default, not btn-primary
- Use form styles/structure like http://getbootstrap.com/css/#forms
I added a branch 2272-setup-user-in-workbench-TC to add notes to apps/workbench/README about getting capybara-webkit/phantomjs to work. Consider merging that into your 2272 branch?
Updated by Tom Clegg over 10 years ago
More notes
- Argh. Is it really worth incorporating into our project some code whose licence is "subject to the licensee inflecting a positive message unto someone"? http://licence.visualidiot.com/ (For that matter, what value does bootstrap-modal.css.scss provide for us that Bootstrap3 doesn't do?)
- Possible fixes for some of the above complaints:
- put the "open modal" code in user_setup.js.erb after updating the div content, instead of using data-toggle in _show_admin.html.erb. Like http://richonrails.com/articles/basic-ajax-in-ruby-on-rails (should avoid showing dialog with stale/empty content)
- Bootstrap says "Always try to place a modal's HTML code in a top-level position in your document" (might help positioning)
Updated by Tom Clegg over 10 years ago
I pushed an updated 2272-setup-user-in-workbench-TC branch with my suggestions for using default styles and letting Bootstrap work its magic:
- Removed the bootstrap-modal.css file
- Moved the modal div into a footer_html section so it goes into the top level of the DOM like Bootstrap recommends (otherwise everything was being rendered strangely because it was inside a blockquote, etc.)
- Used the div structure from the Bootstrap modal docs (.modal .modal-dialog .modal-content .modal-header/body/footer)
- Used the form structure from the Bootstrap form docs (.form-group input.form-control)
IMO the result looks way better, and (perhaps more importantly) it will automatically get better instead of worse when we move to a non-default Bootstrap theme.
Other- Noticed a small bug with validation: if you paste a valid email address, it doesn't trigger "keyup" so the javascript doesn't revalidate. (You can use
$(selector).on('keyup paste', function(){...})to fire on multiple events.) - Instead of using <script> tags, it's a bit nicer to put javascript code in a
<% content_for :js do %>block (or:footer_jsto put it at the bottom of the HTML so the DOM already exists by the time it runs). - Some whitespace complaints. (See
git diff --check master...2272-setup-user-in-workbench) You can tell git not to commit these -- https://arvados.org/projects/arvados/wiki/Coding_Standards#Git-setup - Before merge, rebase so our git history doesn't have the weird-licensed code that we didn't end up using
- Set proper email address in your git configuration → https://arvados.org/projects/arvados/wiki/Coding_Standards#Git-commits
Actions