...
Magda ZacharskaJennifer Eustis Amanda Ros Kimie Kester Martina Schildt (first 10 minutes) Christine Tobias Scott Perry Jackie Magagnosc Kim Wiljanen Peter Martinez Thomas Trutt Jeanette Kalchik
Note Taker: Jennifer Eustis
...
| Topic | Notes | |
|---|---|---|
| 1 | Housekeeping
|
|
| 2 | Quesnelia release update |
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. |
| 3 | Bulk editing large data sets - follow-up |
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. |
| 4 | Searching for null/empty values - follow-up | will be covered during the next meeting |
| 5 | Errors and warnings |
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. |
| 6 | Bulk edit queries - follow up from Slack chat | Bulk Edit Queries Examples |
| 7 | Bulk Edit - in app approach - statistical codes - (UXPROD-3714) |
|
...