2024-01-23 BELA Meeting Notes

Housekeeping

• Attendees  - please add your name to the list of attendees.
• Meeting host -  please turn on Transcript option for the meeting.
• App Interaction SIG is looking for a volunteer who can be a liaison between BELA and the SIG?
• Who can take notes today?

 Quesnelia release update

• Bulk edit (Kanban Board)
• Lists app - will be covered during the next meeting

Bulk Edit: The suppress from discovery now has the boxes apply to all holdings and items checked by default. See this in folio-snapshot. Development is finished and now when you suppress from discovery when you view the changes the column with the data being changed will display.

Bulk editing large data sets - follow-up

• MODBULKOPS-212 SPIKE - Investigate performance improvements
• MODBULKOPS-211 SPIKE - Investigate issues with uploading 500k identifiers
• UIBULKED-210 - IncorrectTokenCountException - we cannot recreate the issue and are asking for examples if you encounter it.  

Why does it take so long for matching records to be displayed for large sets? The developers said there is no limit of records. Magda tested this and it took a long time to upload and it ended up that the records didn't display. There are now 2 Jira issues, the SPIKEs above. The developers will be looking into these behaviors.

What is a SPIKE? SPIKE is a brainstorming for the developers. This type of issue is not to solve the problem, it is to identify the problem.

For UIBULKED-210, this issue wasn't able to be recreated. This can be recreated when a string is forced into an array. The developers would like some examples. If you encounter this incorrect token, please let Magda know.

Searching for null/empty values - follow-up

 will be covered during the next meeting

1. Field level errors vs record level errors
2. Errors vs warnings
3. Before or after committing changes

Current implementation: Error message consistency: field level errors and warnings vs. record level errors and warnings

Duplicate entries: What is the expected behavior? It doesn't keep the same record with the duplicate identifier. One person said that duplicates shouldn't have duplicates. If we have 2 records with ISBN listed twice, is the expectation that if 2 records with the same identified should these be reported as errors? This error is coming from uploading the file. We want to prevent processing the records with the same identifier. The system deduplicates the incoming file for us. If multiple existing records are retrieved from one incoming identifier, then there is an error. We need to distinguish between the duplicates in the list of identifiers that are uploaded and issues with the records that are returned and exist already in FOLIO. Can we separate these in the process? With the uploaded file, could we identify the duplicates before the next step where there are errors with the matching to the record? We need to have a warning accordion. Magda will come up with mockups and language.

Updating one property - no change in value: It's clear. But when you see the green toast, you think what was done was done. Since nothing was changed, there is a vote to have the toast red. Others think the language is fine and the green toast is fine. Should this be a warning? There's a notification that says changes would be made. Instead, you should get a notification that no changes will be made. This makes sense. If there is a larger list where only a part don't change, it would be great to have that in the notification. No change is more a warning than error. We should be able to download the warnings. Do we also need to display the entire record or is downloading enough? Will this affect performance? It may. People prefer to download rather than display with paging.

Updating two properties - no change in value in one: No change is more of a warning than an error. The message isn't confusing. It isn't specific. One person likes to know what has changed and what hasn't. This could be an indicator of a change needed. We should move away from record level to item level confirmation. Can this be a process picked up later? What about a message like "all records changed. Check file for field changes". How do we share the logs? We keep the records of what was happening and we can use this functionality.

Bulk edit queries - follow up from Slack chat

Bulk Edit - in app approach - statistical codes - (UXPROD-3714)

1. What are the most common use cases for editing statistical codes?
2. Should bulk edit cover adding new statistical code types?
3. Should each element of the statistical codes be available for bulk editing?
4. How the data should be presented in Bulk edit forms (UI and .csv files)
5. Should bulk edit concentrate only on adding/removing/modifying statistical codes to instances, holdings and items records?