Generic users (sometimes called dummy users; we will stick to generic) are users in the system who are not actual people.
Erin brought this up a few months ago, but it appears none of the possible needs made it into Jira.
- internal departments and workflow (this book is in Preservation; it's on loan to Preservation User)
- external customers and visitors (this book is being used by a local high school; it's on loan to Local High School User)
- interlibrary loan (this book is loaned to Yale through an ILLiad request; in the ILS it's on loan to Yale ILL)
- test users (self-explanatory)
Review GUI and specific needs.
- All libraries have a need to keep contact info for departmental accounts (e.g., who do I call at the borrowing library if there is a problem).
- Decision: we can use the Notes field, when implemented, to capture that information.
- Contact information fields could also be used for address, notification email, etc.
- Notices - we may want them to not be delivered or be delivered in different ways.
- Almost all of us would send notices to email.
- Patron group could be used for these types of accounts if different types of notice rules are desired.
- Tags are also an option for use (they will be searchable, not connected to any workflow)
General GUI question - username/password
- Can the username / password field on the patron record be used to give patrons access to their account info
- Field is intended for operator accounts, not patrons. Could potentially be used? But you would still need an OPAC / Discovery layer in between. Patron logging into FOLIO, with no permissions on their account, would not go anywhere.
Patty: this is a good example of something we can use for test cases and documentation, in a bug fest environment. Let's plan to do that.
Consensus: there is nothing listed here that would require a new feature request.
Andrea would like to go back to RA to review this discussion to make sure nothing was missed. Erin and Jana also sit on RA, so they will have that discussion and bring anything new back to UM.
|Field requests for the user record - deceased, department|
There are Jiras for a number of fields that we have asked about.
- Is a field really needed for this. What are the use cases
- If someone passes away, you want to know and be able to do things with their record. Record may or may not expire immediately.
- You want to be able to turn off notices. You want staff to know right away when they open a user record that the person has died.
- Is Notes a possibility? Maybe, but then you don't have good visibility, and reporting not really possible.
- Disabling notices is not really possible. You could change a loan policy to say no notices, but then individual notices would have to be changed to have the loan policy changed. There is a Jira for this but it is not ranked highly.
- Consensus: we believe this could be addressed through notes and existing processes that people already do (learn about a death, update record, do workarounds to disable notices like extend due dates far into future, then handle with high-touch protocol)
- We believe a feature to add a block for Notices would be really helpful for this and other scenarios. Question will go back to RA.
- Is this a case for custom fields, or a coded field? No hard / bright line about what makes sense.
- Patty advocates for keeping FOLIO as lean as possible.
- Current institutions have a variety of ways to get this info.
- Duke doesn't have a field, we want it. Expect we could load info through patron loader / identity management process.
- Lehigh gets it, stores in note field
- German libraries use custom fields, populate manually.
- Is Statistical Categories a possibility? Currently implemented in inventory.
- Positives - easy to get in users, list can be populated via API
- Downside - for some institutions list would be very long, settings GUI not great for really long lists.
- Is Notes a possibility?
- Does have note types, but they are capped types at tenant level.
Ran out of time. Patty added to Jira additional fields that we want to talk about and aren't in there - preferred pronouns, alternate name