Idea #3296
Updated by Tom Clegg over 10 years ago
Form fields we want to collect:
* Institution/Company (required)
* Lab
* Website URL
* Title
* What best describes your role (dropdown):
Bio-informatician
Computational Biologist
Biologist/Geneticist
Software Developers
IT
Other
New behavior and implementation notes:
* Add a link in the email address dropdown menu in Workbench called 'Edit profile'.
* Add a new page (@/users/{my_uuid}/profile@) with a form allowing the user to add/edit profile data.
* Get the list of form fields from the @user_profile_form_fields@ configuration value.
* Use standard bootstrap form markup (see http://getbootstrap.com/css/#forms-horizontal).
* Store the values in user prefs: @current_user.prefs["profile"]["title"]@, etc.
* On the "edit profile" page, display (but not offer to edit) the user fields that get populated automatically during the OpenID login process (email, first name, last name, identity_url).
* Add comments to @application.defaults.yml@ showing how to add profile fields.
* The default configuration should be an empty hash (i.e., no form fields are shown, and the link to the "edit profile" page is removed from the email address dropdown menu).
* If any of the required profile keys indicated by the @user_profile_form_fields@ configuration hash are missing from the current user's @prefs["profile"]@:
** Redirect most[1] dashboard pages to the "edit profile" page.
** Add an alert panel to the "edit profile" page asking the user to please provide the following information.
** Highlight the required fields so it's not too hard to find "which one did I miss?" (especially if the profile already existed but the config has added a new required key).
* Trap to watch out for: If admin adds a new required field, next time a tab pane gets refreshed for some unsuspecting user, we probably don't want the tab pane to end up with a "manage profile" link. Perhaps we should skip the "redirect if any missing" logic for requests with params[:partials]? (And methods other than GET)
fn1. Avoid constructing a catch-22 where (for example) the user agreement cannot be signed until the profile is edited, and vice versa.
Structure and example yaml encoding for @user_profile_form_fields@:
<pre><code class="yaml">
user_profile_form_fields:
-
key: organization
type: text
form_field_title: Institution/Company
form_field_description: ~
required: true
-
key: role
type: select
form_field_title: Your role
form_field_description: Choose the category that best describes your role in your lab.
options:
- Bio-informatician
- Computational biologist
- Biologist or geneticist
- Software developer
- IT
- Other
</code></pre>
Example encoding for @user.prefs[:profile]@:
<pre><code class="javascript">
{"organization":"Laidlaw Lab","role":"Software developer"}
</code></pre>