2017-10-05 Resource Access Meeting Notes

Owned by Cate Boerema (Deactivated)
Last updated: Oct 09, 2017
4 min read

Date

Attendees

Goals

  • Users app discussion
  • Requests, time permitting

Discussion items

TimeItemWhoNotes
5 minHousekeepingAndrea Loigman
 Users App

Cate Boerema (Deactivated)

  • Background - How we got to where we are with the Users app and where we are headed
  • Patron group - In a recent RA meeting, some felt that users should be able to be in more than one patron group.
  • Email, phone and mobile phone should be repeatable with a “primary” indicator – This is a comment from the RA SIG in the user metadata doc which I’ve not noticed it before.  This requirement will require changes to what we have implemented so I’d like to better understand the priority.  Also, having repeatable fields like this complicates import. 
  • Users should be able to select to be able to select more than one “Preferred contact method” - The RA SIG also mentioned recently.  Again, that would require a change and we’ll want to discuss priority.
  • Metadata elements - Are they sufficient? Discuss plan for further review
  • Data organization - In a recent RA meeting it was proposed that some user data elements should display at the top all the time, some should reside in a collapsible “Additional” section (like birth date and enrollment date) and some should be bundled in a “Staff details” or “FOLIO operator” section (such as username and password, and permissions).
      • We could, without too much effort, put things into different sections.
      • Access permissions is a different story, though. We could have the display of sections be permission controlled, however, it would only prevent using this UI to access the fields. A user could still access them via a different UI (or none, using `curl`). So this is really not the ideal way to control access. The planned approach for access permissions was to set up two classes of fields: restricted and normal. We'd then allow permissions to be created around those classes. This has not yet been implemented, as it's a lot of work to implement and we had flagged only one data element (addresses) as needing it.

Meeting Notes (David Bottorff)

Andrea
  • Should we have a subgroup to deal with institutional calendars? Yes. Andrea will send an email asking for interest We need enough info for Quilto to get started
Cate
  • Had hoped to deal with requests, hopefully next week
  • but first, concerns about users app, very close to releasing it, want to push it over the finish line
Users
  • Patron Group vs Affiliation - need for one patron group but multiple affiliations
    • Tania: consoritia may need multiple, different privileges at different institutions within the consortium Fenway Libraries
    • Affiliation is different than statistical group
    • You can belong to multiple affiliations, then logic determines the patron group
    • LDAP trees/branches: a single user may belong to multiple branches to one tree or multiple branches on different trees (consortia)
    • so patron group is one to one in this context
    • statistical group and affiliation are missing
    • feeds and whether we need to prevent them from trumping the feed, plan for user import option if silent on given data option, then leave it alone
    • what does Chicago do with the affiliation data?
    • This feels like a bigger issue that needs further discussion
      • Cate added placeholder items to the User Metadata spreadsheet for Affiliation and Statistical Group.  Will pick up in a later discussion inluding the UM SIG.
  • email, phone, mobile phone do they need to be repeatable with a primary indicator or as is, only one for each
    • we do have repeatable address field, difficult for the feed to determine whether to add or override
    • Cate suggests putting this in the parking lot and available for prioritization
    • we need different phone types-home, office, etc. separate from mobile phone
    • phone and mobile phone are insufficient
    • could treat phone similar to address
    • simplest option would be to add some additional phone fields like home, office, mobile, etc. or one phone number per phone type based on address model, multiple phones and emails of different types, which you can define locally
      • Cate added user stories for this work - on hold until we discuss with the UM SIG.  UIU-255 and UIU-254 (plus a number of related issues all of which are tagged sig-ra)
    • do we need expiration dates for address, phone, email, etc. Students having a different address over the summer, etc.
  • users should be able to select more than one contact method
    • now we have one preferred contact method-between mail, email, text, phone, mobile phone
    • can we put this in the backlog? prioritize after UAT?
    • yes, but remove phone and mobile phone from even the single preferred method
      • Cate added user story for this work to the backlog: UIU-261
  • metadata will need to come back to this
    • tabling notes field discussion
  • data organization
    • where should various data display, placing them into separate sections, expand collapse, that's easy
    • permissions around a section would only work for a given UI, not for access to fields based on any possible UI
    • user data is all or nothing view at this point
    • not everything they have checked out, which is separate
    • flag different data elements as restricted, only one was certain address types
    • username is needed at many institutions, would also want expiration date and barcode, other data like date enrolled, etc. could be moved to other sections

Action items

  •