Page Comparison

...

Recording and chat: https://recordings.openlibraryfoundation.org/folio/bulk-edit-working-group

Discussion:

Topic

Details

Housekeeping

Attendees - please add your name to the list of attendees
Meeting host - please turn on Transcript option for the meeting
Other topics?

00:04:59.000
Attendees as always. Please add your name to the list.

00:05:12.000
This. Are there any other topics that someone would like to bring it up?

00:05:25.000
If not, then I will move to the next part, which is development updates.

Development updates

Sprint 157 - status update

Backend work completed and integration with UI started

New module under TC evaluation – all issues brought up by TC have been resolved. The final decision expected on Wednesday, January 25th

Bulk edit rework test plan has been created in Testrail and the functional testing will start as soon the bugfest-like environment is up and running.The testing will verify if the rework did not introduce any regression in bulk edit or export manager

Once the functional tests are complete and are successful the module will be released, and performance tests will start (around February 10th).

00:05:32.000 --> 00:05:40.000
As always, I attach the links to the Jira board and to the snapshot environment. If you would like to take a look at those, please do so, but I also added a quick summary that I will share.

Image Modified

00:05:54.000
So the update for the current sprint is the following:

the back end work has been completed and the integration with the UI started. To remind those who may not remember. Scope of the back-end for the Orchid release, we are reworking the back-end so that Bulk Edit does not depend on the Export Manager. Those will be 2 separate modules. There are no changes planned for UI. Besides the UI log that has been added.
The new module is, has been evaluated by a technical council. They brought up a few issues that were already resolved by the team. The final decision is expected on Wednesday, January 25th, which is tomorrow.
In the meantime, we created a test plan in a test trail that is related to the bug edit rework. I can share the link to the Test Plan.
The testing will start as soon as the bugfest environment is up and running. We just want to test it on the larger data set. The testing will verify that the the backend rework did not introduce any regression on the Bulk Edit or Export Manager.
Once the functional tests are completed and are successful, the module will be released and the performance test will start. That will happen around a February tenth, which is the deadline for the module release. Any questions?

00:08:20.000 --> 00:08:27.000
Is that Firebird's people doing all these tests?

00:08:28.000 --> 00:08:34.000
It's more. The Firebird team has one full-time QA. We got one additional QA who is onboarding with the team. But this is, we are talking about hundreds of test cases that need to be executed.

00:08:46.000 --> 00:08:52.000
I have here the the test plan.

Image Modified

00:08:52.000 --> 00:08:53.000
So there's 177 test cases for Bulk Edit

00:08:53.000 --> 00:09:07.000
67 for Export Manager, and on top of it the team is also responsible for testing OAI-MH

00:09:07.000 --> 00:09:14.000 So we will definitely get help from other QAs that will be going through the test. Those tests will need to happen prior to the release.

00:09:31.000 --> 00:09:33.000 Okay. 00:09:33.000 --> 00:09:40.000 And any questions, or additional comments? About the deadline? If not, then I will move to the next part, which is the item status in progress.

Item status In Progress (MODEXPW-348)

Change to values supported in the Inventory UI (Missing and Withdraw)?

Should it require additional permission?

The functionality is most likely supported by data import. Magda to follow up with Ann-Marie. Related documentation: Item Record Statuses and Data Import

Bulk edit - user permissions (UXPROD-3468)

1. What are the most common use cases for removing or adding permissions?
2. How permissions for the bulk edit should be identified:

User identifiers (barcodes, uuids, external system ids, usernames)
User groups ?? (since they are not employers groups they might not be applicable)
Permissions UUIDs (or should it be permission names or permissions display name?)
Should the hidden permissions be also bulk editable?

3. What data should be presented in the matching records table:

Last name, first name, middle name, patron group?
Permission name or permission display name?

4. Should the user be able to bulk edit mutable, hidden and deprecated permissions?

MMZ:

The decision was made that:

Preview of the matching records will be the same as on the User record bulk edit but will provide a link to the user profile. Nice to have is the count of assigned permissions
CSV in addition to user data will also contain a list of all permissions as listed in the permissionUsers record, separated by comma
On the bulk edit page the user should be able to add and remove permissions at the same time (needed for deprecated permissions)
The list of permissions will be type ahead and narrow down the options
Are you sure form will contain additional columns: Permissions added, Permissions removed

Query tool (UXPROD-3785)

Examples of supported queries

Bulk Edit Use cases

Reviewed use cases and associated existing JIRA tickets or marked which ticket still needs a JIRA to be created.

Follow up questions on:

NumberUse case Notes29

Add a similar feature to Sierra Global Update that allows you to see the data from the fields of the same type (author, subject, title, etc.) present in a set (review file) of records.

Use case – Identify bib records from the daily headings reports that have not been sent for authorities processing.

Example: Backstage inserts a code indicating that a bib record has been processed in the 040 field. I can view all the 040 fields from a set of records using the “toggle” function in Global Update and select records for future authorities processing.

Use case – Find patterns of problems in a set of records.

Example: During record loading, some MARC fields may end up being duplicated. Sierra Create List searching cannot find duplicate fields, but the “toggle” function in Global Update helps identify affected records.

30

Ability to temporarily add or remove a MARC field in SRS.

Use case – To temporarily exclude some bib records from authorities processing, we add a 9XX note and re-write the monthly search query to exclude records using that note.

Example: The recent EEBO record load was huge, so we had to temporarily exclude them from the month’s authorities processing query.

36When the 3-part Item State is available/developed, there will be the need to identify item records based on a 1-part item state, location, etc. in order to update them with one or more of the 3-part states. This could be done based on a list of item records (HRIDs or Barcodes), or by location alone, depending on how the 1-part item state is used with location, or other data, at individual institutions.49

Ability to identify records with certain characteristics (a particular 650, for example) and permanently add a MARC field in SRS and Instance to those records.

Use case: In-house record enhancements (adding new controlled vocabularies such as LCGFT or LCMPT)

57We want to be able to find and delete duplicate fields. We want to be able to specify the field or fields where we want to remove duplicate data. Transcripts





00:09:40.000 --> 00:09:46.000
About the deadline

00:09:46.000 --> 00:09:57.000
If not, then I will move to the to the next part, which is the item status in progress.

00:09:57.000 --> 00:10:12.000
We talked about this last time, and this seemed to be a problem for and Michigan State, do we have anyone from Michigan state on the call

00:10:12.000 --> 00:10:14.000
There are several of us on the call. Yeah.

00:10:14.000 --> 00:10:24.000
Okay, great. So please speak up. If I let me represent something.

00:10:24.000 --> 00:10:36.000
So this functionality, changing the item status from improving progress to available, was never implemented.

00:10:36.000 --> 00:10:41.000
It was. It is by design that in progress is not

00:10:41.000 --> 00:10:43.000
And in process

00:10:43.000 --> 00:10:46.000
In in process. I'm sorry I'm just reading what I wrote, and I wrote incorrectly sorry about that.

00:10:46.000 --> 00:10:52.000
That's okay. That's that is, okay. I just wanted to make sure we weren't missing anything.

00:10:52.000 --> 00:10:53.000
There, sure

00:10:53.000 --> 00:10:54.000
Thank thank you. Thank you. Aaron, for paying attention.

00:10:54.000 --> 00:11:21.000
Yes, in process. So changing status from in process to available was never supported.

00:11:21.000 --> 00:11:22.000
Right.

00:11:22.000 --> 00:11:52.000
Was it by design? Because, as we discussed last time, the in process belongs to receiving, and we, what we implemented is in accordance with the inventory app, however, inventory app currently supports the change of in process to missing and withdraw we can implement that but

00:12:01.000 --> 00:12:02.000
Sure.

00:12:02.000 --> 00:12:05.000
This is kind of opening the the door for workaround, because if you change the status from in process to and missing, or we drown, then you're date are open to change to available, because we support changing from missing, or with John to available

00:12:05.000 --> 00:12:07.000
Sure.

00:12:07.000 --> 00:12:18.000
So for Michigan State use case, they would be able to do this in 2 steps for the items that are in process.

00:12:18.000 --> 00:12:25.000
They, they will change the withdrawal, and then we'll need to change it to available.

00:12:25.000 --> 00:12:32.000
It's workaround. And to be honest, I am not feeling very comfortable about that.

[Magda Zacharska] 10:10:43
But if this is something, this is desperately needed, and then we will need to implement.

[Magda Zacharska] 10:10:43
Please share your opinion and comments.

[Erin Nettifee] 10:10:51
I mean, I think the ability to bulk edit to missing and withdrawn is needed.

[Erin Nettifee] 10:10:56
I mean, we talked about that last time, and if Michigan State then uses that as a workaround for the workflow that they need, then that's up to them.

[Erin Nettifee] 10:11:07
I mean they they know their process is best, so I'm not uncomfortable with it per se. But I don't know if anybody else has, like Jennifer has her hand up

[Jennifer Eustis (she/her)] 10:11:20
Yeah, I, I, I agree. Erin, I I think because it's it's allowed in inventory.

[Jennifer Eustis (she/her)] 10:11:27
I I with Buck Edit, you know, like, if I'm doing this particular action, my scenario would be.

[Jennifer Eustis (she/her)] 10:11:36
You know, we're training new students and perhaps you know the end processing.

[Jennifer Eustis (she/her)] 10:11:41
They went to the stacks, and they still have the in process status when they should be in chargeable, let's say, or something like that, or Mary, our finance person forgets the mittens missing.

[Jennifer Eustis (she/her)] 10:11:53
So we've already done the work to make sure that all the requests are off.

[Jennifer Eustis (she/her)] 10:11:59
The finance piece is done, and all of that. So I think, at least in our case, it it would be fine to make these changes, especially with bulk edit.

00:09:57.000 --> 00:10:12.000
We talked about this last time, and this seemed to be a problem for Michigan State, do we have anyone from Michigan state on the call?

00:10:12.000 --> 00:10:14.000
There are several of us on the call. Yeah.

00:10:14.000 --> 00:10:24.000
Okay, great. So please speak up. If I missrepresent something.

00:10:24.000 --> 00:10:36.000
So the functionality to change the item status from in-progress to available was never supported by design? Because, as we discussed last time, the in-process belongs to receiving, and what we implemented is in accordance with the Inventory App. However, the Inventory App currently supports the change of in-process to missing and withdrawn. We can implement that but 00:12:02.000 --> 00:12:05.000
this is kind of opening the the door for a workaround, because if you change the status from in process to missing or withdrawn, then you're gates are open to change to available, because we support changing from missing, or withdrawn or available

00:12:07.000 --> 00:12:18.000
So for Michigan State's use case, they would be able to do this in 2 steps for the items that are in-process. They would change items to withdrawn and then to available. It's workaround. And to be honest, I am not feeling very comfortable about that. But, if this is something that is desperately needed, and then we will need to implement it.