Page Comparison

...

• (OLD ACCOUNT) Erin Nettifee

• Maura Byrne

• patty.wanninger

• Uschi Klute Klute
• Philip Robinson
• Jana Freytag
• Catherine Smith
• Michelle Suranofsky
• Nancy Burford
• Matthew Harrington
• Kelly Drake
• Theodor Tolstoy (One-Group.se)
• Thomas Paige

Goals

Notetaker: ??? we didn't have a notetaker last week... Phil (again sigh   )

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

...

• Multiple Phone numbers

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UIU-254

  (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 demo'd his handy 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 conveniently 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 

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODLOGIN-38

  
  
  • 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

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key LIBAPP-94

  - 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

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UIU-1255

  )
•  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
•  

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-242

  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

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1790

  ("New feature")
•  Patty will create a feature request for deleting user data.
•  Patty will ask Magda (the reporter on 

  Jira Legacy
  server System JiraJIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1811

  ) for a status.  It may not be a UM-SIG issue.

...

Notes

...

• .

...

Open Topics

...