Meeting URL
Date
Attendees
- Stefanie Sußmann
- Uschi Klute Klute
- Jana Freytag
- Philip Robinson
- Björn Muschall
- someone else?!?
Goals
- Notetaker: Uschi
- Discuss Bugfest Feedback (Steffi)
- CAP Plan Jiras (Erin)
- https://docs.google.com/spreadsheets/d/19j98iCQs41xIUXLJyArvcZwTKWuCMlZflKYkCHHwdAM/edit?usp=sharing - have you reviewed?
- The following Jiras did not make the CAP plan. Do we need to discuss?
- Testing for User Fielded Search, and next steps (Uschi; Erin; - see 2019-09-11 Meeting notes for Uschi's test results at the bottom of the page)
If we have additional time:
- Writing user stories / features for deleting user records through the GUI (Erin, Patty)
- Reviewing requirements that have been created and attached for Custom Fields ( - UXPROD-33Getting issue details... STATUS ) (Erin)
- Feature request for notes on records being displayed in pop-up or other contexts. (Steffi)
- Because this involves the Check in and Check Out apps, this may end up needing to be a feature request for RA to manage.
- Needs for PIN on user records, see what Jiras are existing, talk about requirements (Björn, others?)
Notes
Bugfest Feedback
E-Mail field is required, but there is no validation (Steffi)
- Uschi: seems to be important because otherwise users may not receive their notifications.
- It's a good practice to validate
- Björn: Perhaps the tenant settings could be used to determine whether the e-mail field is mandatory or not.
- Uschi: E-mail should not be mandatory as some GBV libraries have patrons without e-mail address.
- Result / Action item: ???
The fields Status and Expiration date are dependent on each other (Steffi)
- Set Expiration date to future date → Status changes automatically to active
- Set Expiration date to past date → Status changes automatically to inactive
- The meaning (resp. impact) of the field Status is unclear.
- We consider this a bug. The two fields should be able to be filled independently of each other.
- Result / Action item: ???
The field Birth date is not validated (Steffi)
- You can enter a date in the future.
- Result / Action item: Patty creates a JIRA issue.
Password reset (Jana)
- Björn: If no e-mail is sent, this is due to missing settings in the server configuration.
Changing the password manually (Jana)
- Proposal: manage the user data incl. password in the campus ID System.
- Uschi: What if the library doesn't use such a system?
- Might be a solution: Change terms of use → no use of library without e-mail address
- Result / Action item: Patty suggests that Theodor Tolstoy presents the Chalmers SSO solution to us at one of the next meetings.
Extremely strict password rules (Björn)
- It's difficult to find out which character combinations are allowed → It's not userfriendly
- Example: no two identical letters in a row
- Proposal: make the password strength configurable
- Result / Action item: ???
CAP plan JIRA issues (Erin)
- Summary of the institution responses to MVP: https://docs.google.com/spreadsheets/d/19j98iCQs41xIUXLJyArvcZwTKWuCMlZflKYkCHHwdAM/edit?usp=sharing
- Discussing the following Jiras which did not make the CAP plan.
-
-
UXPROD-1744Getting issue details...
STATUS
The UM SIG agrees that this is not important for MVP.
-
-
UXPROD-242Getting issue details...
STATUS
Meaning of CAP comment is unclear. Björn: Perhaps if a field is not delivered (=empty), it will not be overwritten. Phil: But you might want to remove a field in FOLIO during import.
- Result / Action item: Patty will ask the CAP plan group
- - UXPROD-1790Getting issue details... STATUS
- is important for Duke. Was put on hold when the Custom Fields were marked for MVP. But now CF are non-MVP.
- Patty: meanwhile the CF development team was given other tasks. Notes could be used as an alternative to CF.
- Erin: What about the National Library of Florence? They need CF for their FOLIO migration.
- - UXPROD-259Getting issue details... STATUS
- can be closed
- Result / Action item: Patty will add a comment to that JIRA
-
-
UXPROD-1744Getting issue details...
STATUS
- For Q1, only a few issues will be planned; the focus will be on testing, bugfixing and stabilization.
User search facilities (Uschi)
- postponed to next meeting
Open Topics
Item | Who | Notes | Discussed Today? | Resolution / Next Steps | Carry 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: - UXPROD-1015Getting issue details... STATUS - UXPROD-907Getting issue details... STATUS (New feature) - UXPROD-869Getting issue details... STATUS (Epic) - UXPROD-1941Getting issue details... STATUS (new feature) |
| Yes; this is not yet resolved. | |
Pop-ups on user transactions | Steffi | notes 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. |
| ||
Bulk User import | Erin | Does anyone know (or can tell me) what the current, supported approach is (or will be) for bulk importing user records? I can see a github for mod-user-import, jiras for that project with comments that ask if that mod is still being supported. |I can see a very old jira (https://issues.folio.org/browse/MODUSERS-3) for bulk-loading that was last updated last year.I can see a very old jira about performance improvements (https://issues.folio.org/browse/MODUIMP-4) that was last updated last | Patty to ask for info / updates from Ebsco staff while in Sweden next week | Yes; may need additional discussion in group as we go. | |
Deleting User Records | Erin | Discussing the need for deleting patron records (no Jira currently; need for one discussed in comments of https://issues.folio.org/browse/UIU-1079) |
| Yes | |
Custom Fields | Uschi | 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. | Yes | ||
Discussion on PIN needs for user records | Bjorn, others? | Important to discuss - Because the entry of an account password (e.g. university login) in a public space, e.g. self-checkout is not very protective. The input, especially in vertically hanging touch screen monitors, is not protected from the view of others behind me. Also, if I feel someone has been watching me, I can simply change my PIN without having to change my account (university) password. This provides extra security. The principle should be the same as with a bank card, where the account password and card PIN are different. We'd all be surprised if it wasn't that way with our bank, I think. Leipzig does not need this urgently, because we need at least another 2 years for go-live. But in the long run all Saxon libraries need this. | |||
Multiple Patron Identifiers | Additional patron identifiers will not be in the MVP(?). Conversation turns to custom fields and wondering if they are searchable. Will custom fields work for multiple user identifiers? Patty & Erin will work on users stories for:
| User stories have been written. We can probably drop this from our list of ongoing topics. | No | ||
Other | Patty will work on stories for:
|