Skip to end of banner
Go to start of banner

2019-10-16 User Management Meeting notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Meeting URL

https://zoom.us/j/488543197

Date

Attendees

Goals

Notetaker: Phil (again sigh  (wink) )

  1. Theodor Tolstoy will walk us through the bulk load of users.
  2. We will wrap up the discussion about statistical fields.
    1. Summary of the discussion from last week and much more see Discussion Post: https://discuss.folio.org/t/additional-fields-vs-custom-fields-for-statistical-fields-and-codes/2641


If we have additional time:

  • Multiple Phone numbers UIU-254 - Getting issue details... STATUS (Erin)
  • multiple e-mail addresses - There is no JIRA for this? (Uschi)
  • More topics from the Open Topics list

Notes

  • Theo started with the loads he did with Chalmers. Used the Innovative system API to grab the user records, created a script to transform the records to FOLIO JSON format.
  • User bulk loading (mod-user-import) is one of the oldest APIs in FOLIO. Decent documentation, especially on GitHub, and also on the FOLIO Dev site’s API reference. The API is optimized for bulk loading. 
  • Theoretically any batch size would work; Theo settled on a hundred at a time, from the source system, transform them into the FOLIO format, makes JSON batch files.
  • The original file had around 10K users; Theo broke them up into 100 JSON files of 100 users.
    • Each file has an array “user”, and a few params like total # of batch records, flags for deactivating missing users, update only present fields, and record source type.
    • Chalmers has around 12K users; Theo maxed out his testing at 50K users. It takes several hours to do large batches. It's a stable API during long loads. Some FOLIO APIs deal with millions of records and need to be optimized. With Users we can experiment with different batch sizes to see what’s optimal for our own environments.
  • Patty shared the data load testing log is at  https://docs.google.com/spreadsheets/d/1Q3TtDtOaYYYdoH3JyzQasmVyvMmHZ9CbcW5-0UIX9Pk/edit#gid=1572006106 .
  • The UI will crash if the countryId isn’t a canonically accepted one; Theo plans to raise that as a bug.
  • Theo uses Postman to initiate API calls; nicer to use than command line, good for testing. Give it the headers for JSON and okapi, put the JSON into the request body, and hit POST. The first time you run it, users will be added. Subsequently, they’ll be updated. Uniqueness of user name is enforced, along with other details. 
  • Individual users can be deleted via API. Theo gave an example of deleting using a UUID against the delete call (note - be VERY careful with deletions, one could accidentally delete everything!). Need to apply strict permissions to deletions in particular. 
  • The API returns counts of the records created, updated, and failed, along with explanations of which user rex failed and why. Failures can be triggered by other FOLIO modules down the line (data integrity violations etc).
  • At Chalmers, is there a nightly cron? Not yet. Setting short user expirys for now.
  • Theo also showed his one-liner bash curl script to run imports:
  • find /PATH_TO_USERS -type f -exec curl -POST "OKAPI_URL/user-import" -d @{} -H "x-okapi-tenant: TENANT_ID" -H "x-okapi-token: OKAPI_TOKEN" -H "Content-Type: application/json" \; | tee -a log.txt
  • The bulk API is designed to only make you reload the failed records in case of an overall job crash.
  • You can manage permissions for librarian / staff loads with calls to separate APIs.
  • Question about SSO settings, and various user properties that are available there: barcode, external system ID, FOLIO record #, username, email ….
  • Patty will write a user story to add external system ID to user properties in SSO.

The group agreed to postpone talking about the discussion post re: additional fields vs custom fields for statistical fields / codes.

Action items from last meetings

  • (Too strict) Password Rules  MODLOGIN-38 - Getting issue details... STATUS
    • Patty will talk to Khalilah
    • Can group decide on changes we would like to see?
    • Was password strength covered by the Security Audit - were there requirements there that they were trying to meet?
    • We need password strength checking through the New User process - right now, the new user creation allows any password, and the rules kick in with password change.
      • But, if you create a new user with an empty password, you can then send them a link to create a password and that does follow the rules
    • Do we know where the feature is for tenant level control / customization?
  • Patty will ask Khalilah just to confirm what's being planned for Custom Fields
  • Patty will reach out to Holly to get a sense of what might be possible concerning Notes
  • Patty will create a feature to add validation to the (required) e-mail field
    (see also LIBAPP-94 - Getting issue details... STATUS - but these proposals do not appear to have been implemented.)
  • Patty will file a bug or feature to have Expiration date and Status actually decoupled from each other. (also refering to UIU-1255 - Getting issue details... STATUS )
  • Patty creates a JIRA issue: The field Birth date is not validated, you can enter a date in the future.
  • Patty suggests that Theodor Tolstoy presents the Chalmers SSO solution to us at one of the next meetings. Patty will reach out to Theodor to see about scheduling a time.
  • Patty will file a feature to work on password rules. It's difficult to find out which character combinations are allowed → It's not userfriendly. Proposal: make the password strength configurable
  • UXPROD-242 - Getting issue details... STATUS Patty will ask the CAP plan group for feedback. Erin will work with Patty to write a user story for a "thin thread" v.1 of this - a flag or checkbox on record, that if checked, would cause a record to not be updated.
  • Patty will work on a story for preferred name/preferred pronouns UXPROD-1790 - Getting issue details... STATUS ("New feature")
  • Patty will create a feature request for deleting user data.
  • Patty will ask Magda (the reporter on  UXPROD-1811 - Getting issue details... STATUS ) for a status.  It may not be a UM-SIG issue.

Open Topics

ItemWhoNotesDiscussed Today?Resolution / Next StepsCarry topic?

Searching by specific fields

Erin

Right now Users has general keyword searching; we will want to be able to search specific fields - IDs, emails, addresses, notes?

Perhaps one of these issues fits:

UXPROD-1015 - Getting issue details... STATUS

UXPROD-907 - Getting issue details... STATUS (New feature)

UXPROD-869 - Getting issue details... STATUS (Epic)

UXPROD-1941 - Getting issue details... STATUS (new feature)

UIU-1028 - Getting issue details... STATUS (Story)



  • Uschi did additional testing - see notes from 2019-09-11 Meeting notes
  • Erin to discuss with RA SIG requirements for fielded searching
  • Erin to investigate a searching 
  • Patty will create a Feature Request.
Yes; this is not yet resolved.
Pop-ups on user transactionsSteffinotes may be used for communication about users, and pop-ups on user transaction (or displaying of notes) is desired. Khalilah indicated this should be raised as a new feature request.
  • May need to be raised with RA SIG

Deleting User Records

Erin

Discussing the need for deleting patron records (no Jira currently; need for one discussed in comments of https://issues.folio.org/browse/UIU-1079)

UXPROD-291 - Getting issue details... STATUS


  • Patty will make a Feature Request
  • User Stories need to be writtten
  • Topic is also discussed by Reporting SIG

Password validationUschi

refering to Action Item "Create Feature for password rules"

This is the story for the validation of passwords: MODLOGIN-38 - Getting issue details... STATUS

Some of the rules seem to restrict too much. We would like to configure the password strength. See configuration options in the ILS the GBV libraries use now (at the bottom of this page)




Custom FieldsUschi

UXPROD-33 - Getting issue details... STATUS

the tag cap-mvp has been removed, but development goes on


The tag was removed, and this was dropped from the MVP due to capacity (discussed at RA SIG meeting)

We can and probably should review the requirements that Khalilah has generated; they are attached to the master Jira.


Relevant JIRAs we talked about
  • UIU-256 - Getting issue details... STATUS


yes




  • No labels