Users App
(UXPROD-784)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Users App |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Khalilah Gambrell | Assignee: | patty.wanninger |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | cap-mvp, migration-load, po-mvp, q4-2019-spillover, usermanagement | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Users App | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimate: | XL < 15 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Holly Mistlebauer | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front-End Confidence factor: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | XL < 15 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Holly Mistlebauer | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | Holly did estimates because we needed to get something set for the capacity plan ASAP and no one else was estimating this feature. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Vega | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 106 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Ranking Note: | Even though Users will be making use of custom fields, there are a still few fields where it makes sense to just add them to the data schema. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: BNCF (MVP Feb 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Leipzig (Full TBD): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Add the following fields to User Detail Record
|
| Comments |
| Comment by Cate Boerema (Inactive) [ 05/Dec/18 ] |
|
Removing Q1 2019 fix version due to limited capacity in Q1 2019. |
| Comment by Erin Nettifee [ 05/Aug/19 ] |
|
Duke University supports card functions on phones via Apple Wallet and Google Pay, with Blackboard as the backend. That adds to our ID list since many students use their phones as their identification cards. So a student with an issued university ID card who also has an iPhone will have the following multiple IDs that FOLIO will need to support: university identifier (unique ID); netID; barcode (on physical card); iPhone ID (uploaded to Blackboard). So that's 5 identifiers. A student in that scenario who picks up a research work-study at our hospital may get an additional identifier in the system for the hospital's separate door management system. Someone buys them a Google watch, they then might up with seven identifiers. They study abroad at our China campus for a summer, they get eight identifiers that they will expect to be able to freely swap with the physical card. What we want to make clear is we don't see an obvious cap that we would be happy with in the system because we expect this kind of card-of-things ecosystem to grow at Duke, and it will almost certainly appear at other institutions as well. Unlike some of the other fields listed here, identifiers do have business logic and workflow considerations especially in terms of questions about anonymization, SSO, user lookup and connecting user records across apps. |
| Comment by Charlotte Whitt [ 03/Oct/19 ] |
|
Hi patty.wanninger - in a meeting discussing migration of User data, then we talked about the need for an element to store Statistical codes (Statistical categories). These locally-created statistical codes are used to associate a patron with categories of importance to the institution. In the GAPs analysis from 2018 Statistical codes were identified as a missing element - see row #4 in the spreadsheet - https://docs.google.com/spreadsheets/d/1jiMJz-wTBhSkpVrJOFQh2tGmm9-AXATphu2dMcACkws/edit#gid=1182096279
So it seams like an element several libraries would need for their migration, and therefore it might be better to have Statistical codes implemented as a dedicated FOLIO element, where libraries can customize their values in a reference table - and not something each library should implement by using customizable fields. |
| Comment by Erin Nettifee [ 03/Oct/19 ] |
|
Hi Charlotte Whitt. I'll give some feedback with the caveat that I may not understand all of the available feature set that we could get with using statistical codes. One concern about the statistical codes feature was the UI experience in settings - you can't sort any of the values, for example. Most of the universities on the UM call are large and would have department lists that could be several hundred items long. I also can't create a statistical type and then assign a new code to that type (I will report that as a bug - I was just testing in FOLIO-snapshot.) Also, as far as I have understood it, using statistical codes means that libraries would maintain their own copies of the departmental value field. Assuming that custom fields are available for the bulk loader (Khalilah Gambrell, if they were used, it could simply store a value provided by central IDM and then we wouldn't have to maintain our own list. If we used statistical codes instead, we'd have to write a separate integration to update that list with the list of departments from identity management, and then another integration to actually load patrons with those values. Or perhaps those updates could happen in one integration script. But it doesn't seem to gain anything by storing the value in its own table when its already being sent in from the central source and can just go straight into the user record directly. |
| Comment by Charlotte Whitt [ 03/Oct/19 ] |
|
Hi Erin Nettifee - thank you so much for you fast feedback. In Inventory we have implemented Statistical code types, and Statistical codes. These list are maintained as reference tables in the Settings app > Inventory. A similar solution for the User app with reference data could easily be populate with the separate institutions data, e.g. a list of departments from identity management. Maybe Wayne Schneider can say a little more about if there would be a need for two steps in the integration process or updates could happen in one integration script. Re. the bug: can't create a statistical type and then assign a new code to that type - then that's such an annoying bug! It was filed as:
|
| Comment by Erin Nettifee [ 03/Oct/19 ] |
|
Sure, I’ll check again before submitting the bug to make sure it’s repeatable. With regards to using statistical codes, it’s unclear to me what the use case is for that approach over using custom fields. Can you explain that more? |
| Comment by Wayne Schneider [ 03/Oct/19 ] |
|
Erin Nettifee I think that custom fields are a possible workaround for a system not supporting a multi-value, coded field (or controlled vocabulary) for tracking users statistical categories or classes. Some disadvantages:
Different systems support this kind of requirement in different ways. It can be useful to think of a field that contains statistical categories for reporting separate from information that describes the patron or the patron's access privileges. I don't know if that's convincing to the UM SIG members – Charlotte Whitt and I were trying to chase down how the identified gap above was resolved. Perhaps the SIG decided it was not a major issue, after all, and that custom fields meet the requirement. With respect to maintaining a code list based on a central registry – I agree that if that is a requirement, it would be a separate integration to account for, whether or not it is run in one script or two. |
| Comment by Khalilah Gambrell [ 04/Oct/19 ] |
|
I think custom fields can support. Maybe we can get on a call to discuss but I don't see any reason why custom fields could not do what's described. In fact I have outlined some requirements related to it. |
| Comment by Erin Nettifee [ 04/Oct/19 ] |
|
Hi all - a few followups to this this morning. Charlotte Whitt: FWIW, we did scope department as its own field, and that's in process. See
Wayne Schneider: It's not my call as to whether this gets reassessed, so I hope it's not coming across that way. The last time the SIG touched on this was in July - https://folio-org.atlassian.net/wiki/display/UM/2019-07-31+Meeting+notes - and we were looking at a lot of this from the eye of what needed to go in the MVP and trying to be pretty focused on not asking for features that we didn't think were absolutely needed. If you or others from implementing institutions feel its important and should be reassessed, it could certainly be proposed for an upcoming SIG meeting. I do think we're also conflating a bit the use cases where data needs to be managed in FOLIO for users (say, for users created manually,) and use cases where the data is coming in externally and managed externally. In the case of department in the IdM field, as far as I'm concerned, it's already a controlled vocabulary that's controlled outside of FOLIO and so I would want to do the least amount of management possible. Of course, there are also questions then about how fields themselves are editable or not editable, and how much you might need to clean up manually added data. If we did implement statistical fields, I would want UI improvements to the way that they are controlled in Settings. I don't find the UI usable for long lists that have to be managed in the FOLIO GUI. |
| Comment by Charlotte Whitt [ 04/Oct/19 ] |
|
Hi Erin Nettifee - I admit that the Settings pages definitely can be improved. What we use for now is the standard settings component for editing values in reference data. Re. the problem with managing long list in Settings, then this is a known problem. I have an old UX story in for that - but only in draft, and it has not really been picked up. The problems we have for Settings > Inventory > Format is not that different from maintaining a list of statistical codes - both have a category/type, and then the values. See
For the MVP I think Wayne, and I have mostly been thinking about, that we need a place to migrate this data to. It can be Custom fields - but maybe that then will result in, that all the migrating libraries are doing local solutions, for some very similar data; which soon after MVP, then these elements are to be implemented as a FOLIO defined element. But I'm not an expert on User data - so the custom fields might be the right way to solve this |
| Comment by Erin Nettifee [ 07/Oct/19 ] |
|
It sounds like this would be an appropriate topic to bring back to UM, perhaps when Charlotte, Wayne and/or Khalilah can join the call. I'll defer to patty.wanninger and Maura Byrne on any of that. |
| Comment by Erin Nettifee [ 07/Oct/19 ] |
|
A colleague here at Duke also reminded me that custom fields to the LDP (https://folio-org.atlassian.net/browse/UXPROD-1864) did not make MVP, so that may be enough to say this decision needs to be reassessed as well. |
| Comment by Andrea Loigman [ 08/Oct/19 ] |
|
I believe that there are some institutions that are loading 'alternate' name in their current systems. Is that something they'll be able to continue if it's a custom field? |
| Comment by Erin Nettifee [ 08/Oct/19 ] |
|
Hi Andrea Loigman - yes, we should be able to import into a custom field if I'm understanding this Jira correctly: https://folio-org.atlassian.net/browse/MODCFIELDS-10 And then an individual institution can label it as they deem appropriate. |
| Comment by Khalilah Gambrell [ 08/Oct/19 ] |
|
Cate Boerema and patty.wanninger, I like to split up this feature into two The reason I request this breakup is it might make it easier to estimate and breakdown work. |
| Comment by patty.wanninger [ 11/Oct/19 ] |
|
I split this into two features and asked Ian Walls to adopt the bulk load stories. |
| Comment by Erin Nettifee [ 02/Mar/20 ] |
|
It looks like departments was split into its own feature (
|
| Comment by patty.wanninger [ 11/Mar/20 ] |
|
here it is https://folio-org.atlassian.net/browse/UXPROD-2148 Erin Nettifee |
| Comment by patty.wanninger [ 11/Mar/20 ] |
|
Split titles and honorifics into own feature https://folio-org.atlassian.net/browse/UXPROD-2317 |
| Comment by patty.wanninger [ 27/May/20 ] |
|
Add Phone type and email validation never ranked high enough for development. |
| Comment by patty.wanninger [ 16/Oct/20 ] |
|
Related ticket
|