Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Multiple Phone numbers
    Jira Legacy
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUIU-254
    (Erin)
  • multiple e-mail addresses - There is no JIRA for this? (Uschi)
  • More topics from the Open Topics list

...

  • 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 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
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyMODLOGIN-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
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyLIBAPP-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
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUIU-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
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUXPROD-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
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUXPROD-1790
    ("New feature")
  •  Patty will create a feature request for deleting user data.
  •  Patty will ask Magda (the reporter on 
    Jira Legacy
    serverSystem JiraJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUXPROD-1811
    ) for a status.  It may not be a UM-SIG issue.

...

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:

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-1015

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-907
(New feature)

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-869
(Epic)

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-1941
(new feature)

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUIU-1028
(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://issuesfolio-org.folioatlassian.orgnet/browse/UIU-1079)

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-291


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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODLOGIN-38

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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-33

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

  • Jira Legacy
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyMODCFIELDS-10

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
  • Jira Legacy
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUIU-256


yes

...