2022-10-04 Bulk Edit Working Group Meeting Notes

Attendees (please add your name):

Magda Zacharska (OLD ACCOUNT) Erin Nettifee leeda.adkins@duke.edu Erin Weller Jackie Magagnosc Kimie Kester Monica Arnold Christine Tobias Thomas Trutt Sara Colglazier Amanda Ros Donald Depoorter Robert Scheier

Note Taker:

Robert Scheier

Meeting Recording:

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

Discussion:

Topic
UXPROD-3785 Advanced query for single record type	Building search query Previewing results
UXPROD-3468 Removing and adding permissions - continued from the last meeting	What data should be presented in the matching records table: * Last name, first name, middle name, patron group? * Permission name or permission display name? Should the user be able to bulk edit mutable, hidden and deprecated permissions?


Housekeeping Attendees - please add your name to the list of attendees Meeting host - please turn on Transcript option for the meeting	Magda 8:27 Thank you to those who already added your names to the attendee list. We have 15 participants at this point in the meeting. And I don't think I see 15 attendees on the on the page. So please, please add your name to the attendees list.
Bulk edit documentation for Morning Glory Thank you (OLD ACCOUNT) Erin Nettifee and @Bob Scheier, @Emma Gollner, @Christine Tobias and @Amanda Ros!	Magda 9:01 Thank you so much to everyone who was involved in working on bug edit documentation for Morning Glory. It is so nice to have a new release with updated and very thorough documentation. Thank you so much. Erin 9:23 We still need somebody who can own this app going forward with the documentation working group. So if that's something you think you might be able to do, please message me or Christine and we can talk further about it. Both Christina and I already have big areas we are responsible for so it would be really hard for us to continue to own the bulk edit app documentation.
Development updates Development status Development team scrum board Recordings of implemented Nolana functionality can be found here	Magda 9:56 Development updates--there are links to the scrum board and to the snapshot environment. I highly encourage everyone to play with Bulk Edit in the snapshot environment. The majority of the functionality that was assigned to us or that we committed to do in Nolona is already in place. So you should be able to update user records. Erin 10:41 Snapshot, not the performance environment? Magda 10:47 The performance Bulk Edit environment URL has changed because we added support for multi-tenant environments. I will post the new URL in the Slack channel. 11:07 [Magda reviewed the Bulk Edit functionality in the Snatshot environment at this point in the meeting. ] Unknown Speaker 11:51 packet did I choose the file Magda 14:13 Please spend some time in snapshots, I do agree there is hardly any data. Now, I will start planning out user acceptance testing in the performance testing environment so we have a larger data set. Any questions? Bob 15:33 I'm just a little confused about why we can't do it in the performance environment. Magda 15:50 I will I don't remember exactly the new URL which has changed. And also the performance environment is not automatically updated with the latest code. So whatever you see in the snapshot environments may still not be deployed to the performance environment.
Morning Glory release notes Bulk edit: required configuration known limitations known issues	Magda 16:18 So let's go to our agenda again. And let's move to the next part, which is the Morning Glory release notes. As you know, morning, Glory was released on September 16th, and I would like to walk you through some points on the release notes. So first, the new app. There is only one a new app which is Bulk Edit in Morning Glory. And a quick overview what we support. In the in app approach, inventory items temporary and permanent locations and item statuses. In the CSV approach, user records. There are two sets of permissions that are required for this application, in app edit and view, and CSV edit and view. Depending on those permissions a user can access those applications. There are known there are Known limitations. As our performance tests discovered, in Morning Glory, you can only do a Bulk Edit of 2500 user records at the time. And for items, the limit is 10,000. This is a lot less than we were hoping for. Unfortunately, this is what it is for Morning Glory. We are looking at architectural changes to support a larger data set in the future. Magda 18:54 The last part here, module configuration, is for those who are hosting themselves. For everybody else, this is being set by the hoster. Those are the memory requirements for the container that runs the module data export worker, which is being used in Bulk Edit Erin 19:01 The performance test the performance work that you were talking about, is tracked in a particular Jira? Magda 19:09 JIRA and reports. I will link the list. There is a new performance testing Jira that we started in the Morning Glory. Some of the work will spill over into Nolana. Starting next week, we will be working on bug fixes for the functionality that was already delivered and testing, performance testing, adding API tests, and adding automated tests for the UI. So, most of the tests can be run automatically. Regarding the known issues, there are two Jiras that are linked to Bulk Edit. One which we discussed a couple of meetings ago, has to do with Bulk Edit results triggered by holdings identifiers. When the mapping between holdings and items is not one-to-one, it may happen that the list of identifiers is shorter than the list of matched items. This will need to be addressed in Nolana. We will be working on this functionality. Then the next issue is a little bit more serious. When you update datasets larger or larger than 10,000 records, there is a significant delay of up to several minutes before the display of the preview screen, i.e., the "are you sure" form. We are working on improvements. Erin 22:59 Did you ever see it timeout or just it would always come? Magda 23:05 We saw this, but it happened rarely. So I cannot tell it never happened. Yes, we saw that happened. But if this is the case, you just need to submit the Bulk Edit again. The data is not committed at this point. Any additional questions? Erin 23:55 Jennifer has a question in the chat. "Does it affect any other operations happening at that time?" Magda 24:34 So the problems we saw with slowness are is caused by the mod data export worker that is being used. So separate from the inventory module or a data import module there should be no interference. However, if somebody exports EDIFACT or circulation logs are being exported, or bursar is being exported at the same time, it will have an effect. However, in our tests, when we ran all of those three exports at the same time, EDIFACT, bursar, and circulation with a Bulk Edit of more than 10,000 records, that is when we say it affects other exports happening at the same time. Any other questions?
Holdings source - Inventory vs. bulk edit (MODEXPW-247) In inventory app, if the holdings record is not populated, it assumes that holdings source is the same as the instance record. Is that expected behavior for bulk edit as well?	Magda 26:55 Then I will move to the next part of our meeting. I would like to ask you about the behavior of the holdings source. There is a different behavior in inventory than in Bulk Edit. In Inventory, If their holdings source is not populated, the UI assumes the source of the instance that the holdings is associated with. In Bulk Edit, we don't do this because I am afraid this is a dangerous process. But I may be wrong. So I would like to hear your opinion. This is this JIRA, the screenshots will demonstrate the issue. So the question for this group is are you comfortable with the source being left blank here because it's blank in the database? Or would you rather we follow the inventory behavior? Erin 28:33 So are you're saying that if the Holdings Record doesn't have a source, it assumes it's the same as the instance record? And is that implying that it just displays it in the UI, but it does have value in the underlying record? Magda 28:50 That's correct. So this is what is happening here in the inventory UI. The UI populates this field with the data that is actually coming from the instance. Erin 29:05 That seems weird to me, but I don't know how the metadata folks feel about that. This is not the only place in FOLIO where the UI shows you something that doesn't isn't actually in the underlying data. Jennifer 29:23 That seems really strange. I know. We've had problems with that in the past. So it depends. So for example, if you have Mark holdings, rather than folio holdings, you can edit that and quick mark. So I think having the source is important to know like which we can open it. That was my understanding. And I know for us in our case, well at least as far as I know, the source should be null anywhere. Erin 29:59 Right. Are we seeing this in places other than the reference data, the reference environment?