Page Comparison

Meeting URL

...

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

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

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

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

   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. 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

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

   .  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 https://wiki.folio.org/display/UM/Active+and+Inactive+Status)

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

...