Skip to end of metadata
Go to start of metadata

Meeting URL




Notetaker: ???

  1. Additional fields.  While talking about implementing Users, some RA folks said that there were some things, like Statistical fields, that are essential to our functioning.  We were going to use custom fields for that, but I was asked whether other libraries needed Statistical fields.  If there were enough of us who needed statistical fields, we could advocate for them as additional fields instead of custom fields.  The discussion has begun in Jira ticket UXPROD-1295 - Getting issue details... STATUS , and I’d like to have some discussion at our meeting.  Wayne Schneider from Index Data will be joining us for this part of the meeting, so I’m putting it first.
    More JIRAs for this topic: UIU-1196 - Getting issue details... STATUS
    1. Statistical fields
      1. Björn (cannot attend today) wrote: Regarding Statistical fields, Leipzig would use Custom fields for that.
      2. Statistical Categories
        • We had discussed as part of departmental field - ended up deciding for that as a default field with its own Jira
        • Sense that we would use custom fields for these needs? 
    2. External System ID: discuss the mockup:
  2. Patron Notes: We had this on the agenda last week, but we postponed.
    Notes, especially regarding tickets for external ID and departments
    1. Feature request for notes on records being displayed in pop-up or other contexts. (Steffi)
    2. Because this involves the Check in and Check Out apps, this may end up needing to be a feature request for RA to manage.
    3. Last week we had a discussion about whether blocks would function - can we get an information block? Or something on the notes with a flag?
  3. Active/Inactive vs. Expiration date.  Patty has updated UIU-1255 - Getting issue details... STATUS .  Patty wants to discuss what we think would be the requirements to get this to work the way we want it to. 
    1. Björn wote: Regarding Active/Inactive vs. Expiration date I think Active/Inactive should be able to be set manually at any time and Inactive should also be triggered by Expiration date. An error message that the expiration date must be set (as stated in UIU-1255 screenshots) is not a good option for us. 
    2. Erin: Cate Boerema mentions in a comment that she thinks that part of the buggy behavior is because we are trying to allow both things – manually setting it, and having it controlled by the expiration date. She may be getting developer feedback in that, I don’t know.
      Because we have decided that an expired account should not be allowed to be active (which makes sense, logically) there needs to be some sort of code that connects the two features.
      Cate mentions a use case where FOLIO active / inactive controls the ability to log in. I know that Jana has also mentioned that too many password errors flips a user to inactive as well.
    3. So, we have use cases (from this and from

      • If a user record exists, but they should not be allowed to log in, you would flip the patron to inactive.
        1. Presumably you could also do this by removing all permissions from the record.
        2. This is a manual use case.
      • If a user tries a bad password too many times, they become inactive.
        1. This is a basic need – if we removed it, it would have to be compensated for somewhere else.
        2. This is an automated use case.
      • Patron has lost their card, or access to their account needs to be temporarily suspended.
        1. This falls under the category of “temporary suspension of patron privs” as opposed to temporary suspension of operator privs.
        2. This could potentially be handled through user blocks.
        3. This is a manual use case.

FYI: More Wiki pages for Users (by Erin): Users and Settings - Users and Settings - Circulation - Circulation Rules Editor

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

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


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


Discussing the need for deleting patron records (no Jira currently; need for one discussed in comments of

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