Extend User Metadata v1
Description
Environment
Potential Workaround
Attachments
blocks
is blocked by
relates to
Checklist
hideTestRail: Results
Activity

Cate Boerema June 12, 2017 at 7:12 AM
Cool! I entered UIU-75 to track the work for that.

Niels Erik Nielsen June 12, 2017 at 6:28 AM
Nice! Very cool feature, John.

John Coburn June 12, 2017 at 4:48 AM
It would only be slight modification to have the datepicker lean more on the locale than the hard-coded format string for its presentational format. It already leans on locale for its calendar rendering, so that aspect should already function as expected.
The date library we're using, Momentjs, has quite a number of locale objects - and each holds a set of "Long Date Formats" that contain the numeric month, day, year combination that is supposedly preferred by that locale, falling back to "en" with "MM/DD/YYYY" if the supplied locale string does not exist.
Some example mappings that it has:
French: "fr" - "DD/MM/YYYY
Swedish: "sv" - "YYYY-MM-DD"
Danish: "da" - "DD/MM/YYYY"
German: "de" - "DD.MM.YYYY"
Chinese (Hong Kong): "zh-hk" - "YYYY年MMMD日"
For the interested, a full list of them at https://github.com/moment/moment/tree/develop/src/locale (sans 'en', since that's default)
I will include this change in the next update to stripes-components. Shouldn't break anything, but the hardcoded "dateFormat" props would just need to be removed, and the locale passed in through the 'locale' prop.

Niels Erik Nielsen June 9, 2017 at 4:16 PMEdited
The ghost text is currently hard-coded by ui-users as a parameter to the component (but it's also the date picker components default IIRC)

Cate Boerema June 9, 2017 at 3:59 PM
You can definitely infer a date format from a selected locale - we are already doing it for date display in FOLIO. The question is can you also do it for date input? I was sort of expecting the date picker component to vary depending on the selected locale. So, the ghost text displaying in the field would display in the format associated with the locale as would the format of the selected date... If this is really hard, it's probably not a deal-breaker, but I wondered if it had been considered. Tagging for his thoughts.
Purpose: To extend the user metadata collected in accordance with the User Management SIG discussions which are captured in this document: https://docs.google.com/spreadsheets/d/121RpsJNaewhQEKb7k58eNVIhZ7N9oSWowNRJGYjPJ2M/edit
Acceptance Criteria:
User Metadata Docment
Fields where User Story = UIU-28 are in scope for this story
Create, view and edit mode of the user record all need to be updated
Field labels should be as shown in "Field Label" column (please pay attention to the label case and include asterisks where noted (these denote that the field is required))
Form edit controls (and values, where applicable) are specified in the "Input Type" column
Default values and functions are specified in the "Default Value/Function" column
Required fields are indicated in the "Required" column. Please note, some of these have input controls that will ensure they are populated (when records are created via the UI). Others will require a validation message if left blank but that is out of scope for this story (see for the validation story)
All other columns in the User Metadata spreadsheet can be ignored
Out of scope: Per FOLIO roundup, warnings thrown when preferred contact method isn't populated is out of scope for this story. I'll create a separate story for that and link it here.