2023-1-10 Bulk Edit Working Group Meeting Notes

Housekeeping

• Attendees  - please add your name to the list of attendees

• Meeting host -  please turn on Transcript option for the meeting 

• Bulk edit meetings evaluation - please provide your feedback: https://forms.gle/iwRM1zq7id34Jgzt8

• Other topics?

[Magda Zacharska] 10:04:06 Okay, and please add your name to the attendees.

[Magda Zacharska] 10:04:15 Least I think we have more than five people attending. [Magda Zacharska] 10:04:49 The third bullet is the Bug edit meeting evaluation.

[Magda Zacharska] 10:04:58 I posted it during our meeting last meeting last year, and thank you to those who responded.

[Magda Zacharska] 10:05:09
But I would like to hear more from from those who are attending the the meetings.

[Magda Zacharska] 10:05:18
This is a your way to tell me what what you would like to improve.

[Magda Zacharska] 10:05:26
Also, I do appreciate any positive feedback. [Magda Zacharska] 10:05:34 But the the survey is anonymous. So feel free to to be as honest.

Development updates

• Development status

• Development team scrum board

[Magda Zacharska] 10:06:11 Okay. Let's dive in the development status and the scram board.


[Magda Zacharska] 10:06:30 Most of the work we are doing is on the back end. We are changing the architecture that separates the Bulk Edit operation from Export Manager, and there is not much on the front end. [Magda Zacharska] 10:06:51 By the end of this week we hope to to finish majority of the work, and we'll start testing to make sure no regression was introduced. I have high expectation for this architecturing will improve the performance and other issues that we have encountered. [Magda Zacharska] 10:07:18 As you can see, the team is working also on OMIPMH and improving testing. So that adds to to the workload for the team.

Item status In Progress

Currently not supported for bulk editing but the Inventory UI allows changing it to Missing or Withdrawn.  What are the most common use cases for such changes?

[Magda Zacharska] 10:08:12
The next question is related to Bulk Edit functionality.

[Magda Zacharska] 10:08:43
And couple of weeks ago one of the institutions reached out to us, reporting that they are not able to update statuses from in progress to available.

[Magda Zacharska] 10:08:54
That is by design. The UI in Inventory allows for changing to missing and withdrawal. It does not allow changing to available. I would like to ask you for your feedback.

[Erin Nettifee] 10:09:36
That makes sense to me in that context to not allow moving items from in process to available, because that's what the Receiving App does. I think the use cases for moving it to missing or withdrawn is a essentially that something either wasn't properly received, or maybe something just happened with an order.

[Jennifer Eustis (she/her)] 10:10:29
After our migration a lot of things came over as in process for some reason, so it would be nice to be able to change them.

[Jennifer Eustis (she/her)] 10:10:40
That another thing is, sometimes it just gets missed. Another issue that I've noticed is with order packages those generally don't go through receiving. Our workflow is to add a peice and then we receive it. But noticed that it is clunky, and sometimes there are errors.

[Jennifer Eustis (she/her)] 10:11:19
Once an items goes out of an area, sometimes we need to put it back into in process. So I guess that's the vice versa of going from in process to another status. So I would say, you know, it'd be great to go in process to either available missing or withdrawn, or for us, if you include for special collections, restricted or unavailable and in process as well.

[Lynne Fors] 10:12:04
So I can see using in process when we have things that are in-house repair. So it's in the process of having something done to it, but it's outside of the receiving process. And then moving to either available or withdrawn if it's something that we just can't fix and we have to buy replacement copy.

[Magda Zacharska] 10:12:32
Wouldn't this be the unavailable status if this is an internal processing?

[Lynne Fors] 10:12:39
We use unavailable for some things we're still figuring out our workflow since we just completed our migration.

[Lynne Fors] 10:12:51
But we're also using in process to indicate things that have already been received.

[Lynne Fors] 10:12:56
They've been through cataloging, and now they're going through in process to get their properties stamps and call number labels, and then it gets checked in. It's also a function of catching the ones that got missed when our student workers may have skipped to step in the process.

[Erin Nettifee] 10:13:19
So, yeah, so I think that when this was discussed at RA, which was a long time ago, the use cases like the one you mentioned, an item being in repair, was the reason that in process/non-requestable was added. So in process kind of had this special meaning with the ordering workflows.
But other things could be put into in process/non-requestable if you wanted. So, it's not disagreeing with your use case per se, but it's the reason that that particular second version of in process was implemented.

[Magda Zacharska] So that would fall into the category in process non-requestable, which is supported.

Open

[Erin Nettifee] 10:14:23
Yeah, and then Leeda mentions in the chat that they have a common use case in Bulk Edit of moving an item from missing to long missing, and that is supported. But that a status change of an item from available to missing would be done manually. And then,
Jenn says, can in process/non-requestable get updated without check-in, and it looks like it can.

[Erin Nettifee] 10:15:03
So I guess Magda, my thought process on this is, I think there are definite use cases for taking something from in process to missing and in process to withdrawn. I think the issue is, a library could end up messing things up with receiving. But it's also hard to just say you never want to allow that at all, because they're definitely used cases for it, and every library is going to operate slightly differently.
So it's not like we can just define specific blocks. You kind of just have to provide documentation and let people do what they think is best for them.

[Magda Zacharska] 10:15:59
Okay, thank you everyone.

[Erin Nettifee] 10:16:13
So it sounds like we would add a feature to support that?

[Magda Zacharska] 10:16:20
Yes. So from the development point of view, adding new status is relevantly straightforward.

[Magda Zacharska] 10:16:50
My concern is that we are opening the gate for something that will lead to the data issues.

[Magda Zacharska] 10:17:18
And after I digest the feedback you provided today, we'll see what we can do to address the issue safely.

Nolana UAT updates and feedback

UAT Scenarios

We got more responses this time.  Did this form (Excel file with scenarios) worked better than the survey used in prior releases?

Review of suggested feedback:

[Magda Zacharska] 10:19:19
 The first comment:  "It would be nice if you remember another edit you need to make you could use the same set of records to do another bulk edit under action rather than needing to go back to New bulk edit."

[Magda Zacharska] 10:19:25
We talked about this. The new bulk edit button was a fix for the issues we were having with retrieving the data.

[Magda Zacharska] 10:19:41
I really hope we will be able to address this with architectural changes.

[Magda Zacharska] 10:19:49
Hopefully, we will be able to get rid of the of the button, but you will still need to upload the same list of identifiers. Is this not what the person who wrote the common had in mind?

[Erin Nettifee] 10:20:30
I wonder if that's a piece of feedback to maybe revisit this in another release if more libraries use it.

[Jennifer Eustis (she/her)] 10:20:40
Yeah, that's a great comment, Erin. I think when I was testing this in our MorningGglory dry run, I would just click new edit and start the process again. And that seemed fine to me. But maybe that is because, in our old system, we really could not do a lot of global changes. So maybe once we start using it more I will have a better sense of what I'm forgetting, and what I'd like to do with it. Like if I want to go back and do something else to that data set.  This also might be wrapped up with what we were talking about how to save sets in FOLIO. For example, I have a set of bar codes, and I do tons of things with these items all the time, and I just want to save that and do operations on them every year. Or maybe there's an exhibit every year, or something like that.

[Magda Zacharska] 10:21:51
So we have a JIRA in the Data Export backlog that would allow users to save a list of identifiers within FOLILO so you don't have to upload it over and over again. But it also overlaps a little bit with the functionality that we talk about for Bulk Edit where the user will be able to save a query and then reuse it later, which is related to, and the query tool we will be talking about a little bit later.

[Magda Zacharska] 10:22:50
The next comment was: is the extra error "no change in value needed" necessary? If something is an error I would expect it not to be changed so it makes the errors look twice as long."

[Magda Zacharska] 10:22:58
I agree that this is not an error, it's a notification. Maybe we should consider separating errors from notifications. Right now we have only one area where we notify the user that something did not go as expected, or could not be completed for different reasons. And one of them is that there was no change in the value of the records. There are 2 options. One, suppress this information and do not show it at all, or start thinking about a notification area separate from errors. What does the group think?

[Mark Arnold] 10:24:07
Which one would require the least amount of work?

[Magda Zacharska] 10:24:11
Suppressing, I think it would be less work. But I'd rather show more information that may not be truly relevant than suppress something that would not be expected to be suppressed.

[Erin Nettifee] 10:24:34
I agree with that?

[Mark Arnold] 10:24:36
I prefer separating the notifications from the alerts. I always prefer to keep those 2 separate.

[Erin Nettifee] 10:25:20
Anyone else have any thoughts on this one

[Kimberly Wiljanen] 10:25:24
I'm thinking that if you've got a large file, it would be helpful to know which ones were not changed.

[Magda Zacharska] 10:25:43
If you have 5,000 records, and 500 of them did not require changes, are you saying you don't find this information useful? Is this what you are saying?

[Kimberly Wiljanen] 10:26:11
Well, if you've got things that don't update, it helps to know which ones didn't. But if you got 500 that didn't require it, that's a whole different ball game.

[Erin Nettifee] 10:26:24
Right. And I think a question for the developers is how do you distinguish between something that didn't update because we didn't need to or something that didn't update because there was a problem and how easy is it to distinguish between those 2?

[Kimberly Wiljanen] 10:26:45
If there's a problem, you really want to know that it didn't update.

[Magda Zacharska] 10:26:53
So that if there was a problem and it didn't update. So, for example, when a user tries to update an item that is in process to available, it is not being updated, but it tells you that this is not supported.

[Kimberly Wiljanen] 10:27:18
Yeah, that's a little closer to it.

[Magda Zacharska] 10:27:31
The next feedback that we received was that the records were not updated: "two records did not fetch create or update." After those 2 JIRAs (MODEXPW-319 and MODEXPW-320) were implemented and deployed I was not able to recreate that issue.

[Erin Nettifee] 10:28:05
I think I reported that, or I reported something similar, and if you couldn't recreate it, then I think it's fine

[Magda Zacharska] 10:28:16
Next comment is regarding the expiration date for user records. The cursor goes into a year box which makes it seems that you should be able to edit the date by typing. We are using the default component so I believe this is the same as in other applications. If this is, if it's not, please let me know. If you think we need to improve the behavior. What do you think should be a better behavior?

[Erin Nettifee] 10:29:02
I actually don't think allowing people to type is a good idea because we have had different kinds of bugs where people type the wrong information, like a badly formatted date, and if it ends up no getting transformed properly you can cause issues. There was actually something that was a big issue going from Lotus to Morning Glory with user records because you could save a birthday of January 1, 1900, and people were doing that by typing in data. So maybe this is just something we could take back to stripes. But I wouldn't want to change it just in the Bulk Edit area.

[Jennifer Eustis (she/her)] 10:30:17
Doesn't the calendar come up with that?

[Magda Zacharska] 10:30:20
Yes.

[Jennifer Eustis (she/her)] 10:30:21

I think that that's like normal behavior in other places. So, yeah, I agree. Because I think we only see the date. I like just being able to select a date using the the calendar pop up.

[Magda Zacharska] 10:30:51
I will discuss this with the stripe teams and see what we can do if we can do some enhanced data validation.

[Magda Zacharska] 10:31:03
Obviously the format has to be a date, but the date needs to be reasonable. We will probably come back to this as well. The next comment is about the item statuses: "It would be helpful to know which statuses can be changed."

[Magda Zacharska] 10:31:38
What would be the best way to inform users? I checked the documentation. The documentation does not contain this information.

[Magda Zacharska] 10:32:06
So maybe adding it to Bulk Edit documentation would be something. I don't think we would like to crowd the UI with this information. But I may be incorrect.

[Erin Nettifee] 10:32:22
So one thing that we've been talking about in RA that I actually think is good is in some of the acquisitions apps they've started doing, or they've implemented a tooltip kind of thing, like a little blue eye next to a term. And you can hover over it and get some help. I think it would be worth looking at that to see if there's text we could present that would provide good information. But I also think that we could very easily get this into docs.folio Information. That is not difficult. So we just need to surface it more and encourage people to look at the documentation If they're not sure how it would work. It actually didn't click in my head that this was here, and Amanda is now doing the Bulk Edit docs, and she had to drop off for another meeting. But I think adding this to that section would be trivial.

[Magda Zacharska] 10:33:23
I was thinking about the tooltip because we did it in the data export as well for things that are not straightforward. But this is a lot of information to put into a tooltip. And I don't know what would be a better way.

[Erin Nettifee] 10:33:44
It could be some generic phrase like, some item statuses can and can't be changed. I don't know if you can do a URL in a tool tip. I think there are different ways. We could explore that. But the first step is to add this to the documentation, which we can easily do.

[Magda Zacharska] 10:34:38
The next comment, "I selected the wrong identifier from the drop down. The error message wasn't that clear. There was still a preview of the holdings records and then errors for each one. It would be nice at some future date to have the error read that the identifier weren't uuids.

[Magda Zacharska] 10:34:59
I assume that the list provided contained HRIDs but the selected dropdown was expecting UUIDs. That would be difficult to implement, actually.

[Erin Nettifee] 10:35:24
Well, there's a pattern you could match on for UUIDs, right?

[Magda Zacharska] 10:35:27
Yes, but if you have holdings UUIDs, and you provide items UUIDs instead, you still will have 0 marches, and you will not know what went wrong.

[Erin Nettifee] 10:35:48
Sure.

[Erin Nettifee] 10:36:01
What error message shows up.

[Magda Zacharska] 10:36:04
No match is found.

[Erin Nettifee] 10:36:10
Yeah, I would think that if that happened I would think, oh, my identifiers were wrong. But I don't know what other think.

[Magda Zacharska] 10:37:28
I will follow up with developers if they have some ideas.

[Magda Zacharska] 10:37:40
And the last one. "I added a 3rd action, then deleted it. When I clicked 'Confirm changes' I got a 'Something went wrong' error. I had to start over. Without the added action added and deleted, the step was passed." I think for the first time I saw it when I was demonstrating Bulk Edit for holdings to this group. Then it it started to occur in the bugfest environment. We did the fix and it turns out the the issues intermittent. So what we decided to do to mark it as a known issue. If it occurs, the user needs to start the whole process over again.

[Magda Zacharska] 10:38:38
This is another issue that I hope improves with the new architecture.

Uploading progress bar

Query tool (UXPROD-3785)

When uploading large file the progress bar stays in the same place for a while:

[Magda Zacharska] 10:39:15
I will move them to the next element

[Magda Zacharska] 10:39:21
When we are uploading a large file of the identifiers. I'm talking 10,000 records, the progress bar stays in the retrieving position for a very long time. So there's nothing in the UI that indicated that something is happening, and the user may have an impression that the job is stuck on the back end.

[Magda Zacharska] 10:40:06
However, we know that something is happening because we see the list of the process records increasing in the browser Dev Tools.

[Magda Zacharska] 10:40:19
I was wondering if it would make sense to change the label here from retrieving to something that would notify the user, that so and so records were processed.

[Magda Zacharska] 10:40:37
So that even though the progress bar is not moving, yet, we see that there is work that is happening.

[Kimie (Keemee) Kester] 10:40:53
If the dots are animating there are some dots right next to the retrieving, then that generally means that something is happening, even though the devs can't move that blue bar at least that would give the users some hope that something's happening is that what you're saying?
Are you saying they can't even animate the dots?

[Magda Zacharska] 10:41:19
No, no, they are, and they are animating. I just think this is a little bit too small. I would hope to have more visual information because the first thing you see is the progress bar and that it looks stuck.

[Kimie (Keemee) Kester] 10:41:40
Well, you know, we could change the design of that if the issue is at the back end; they cannot calculate when to move that blue bar which is what I think you're saying?

[Magda Zacharska] 10:41:52
Yes.

[Kimie (Keemee) Kester] 10:41:52
Then we could, you know, okay, I guess this is what you're asking.

[Kimie (Keemee) Kester] 10:41:59
Maybe you want to change the labeling, but maybe what we could also do is we could change the way that those dots are styled so that they're bigger, bigger could look more exciting.

[Erin Nettifee] 10:42:14
I was not even aware that you would be able to track the progress that way in browser developer tools. So that makes me wonder if you could even expose the number counting up.

[Magda Zacharska] 10:42:31
So this is what I want. This was my original question actually, if it were to be helpful if we show like 100 record process, 200 records processed, etc.

[Erin Nettifee] 10:43:19
Yeah, I think that if there was a way to expose the count of records, something like 600 of a 1,000, you know, or to kind of show that it's counting up.

[Erin Nettifee] 10:43:39
I also think, though, that that might be a little weird.

[Erin Nettifee] 10:43:43
If you're doing that, and you also have this very tiny bar that's not moving right like that could also feel strange.

[Kimie (Keemee) Kester] 10:44:25
Then why can't they move the visual blue bar forward if they have a count?

[Magda Zacharska] 10:44:39
Because at this point there are 2 steps. First, they're retrieving the records. Then they are saving them in the file. And that is stored in the module locally. And this is the file that is being presented to the user.

[Magda Zacharska] 10:45:02
So right now they're retrieving. It is not even if they retrieve, or 10,000 records, the work is still not done because they are still saving. They need to save, and this is once they start saving than the progress bar progresses.

[Kimie (Keemee) Kester] 10:45:30
Hmm.

[Erin Nettifee] 10:45:48
There are a couple of people in chat saying that they would like to see the numbers. That would be helpful.

[Magda Zacharska] 10:45:59
Okay we think about that, we'll probably come back to this there later.

[Magda Zacharska] 10:46:10
The next question that I have is related to the work we ae doing for queries.

[Magda Zacharska] 10:46:27
And yesterday, talking with the developers, I was made aware that the part that is highlighted in in blue is a very expensive call.

Open

[Magda Zacharska] 10:46:42
This is the tool that will allow users to build the the query.

[Magda Zacharska] 10:46:52
Once the query is built, this is the table that you see above the test query button.

[Magda Zacharska] 10:47:27
And here we see the preview of 100 records.

[Magda Zacharska] 10:47:34
The preview can be scrolled down where you will see 100 records

[Magda Zacharska] 10:47:42
But I do believe it's important from the user's point of view, to know how many records will be returned.

[Magda Zacharska] 10:47:51
I was told by the architects that this part is extremely resource greedy because it would require that the query tp actually run.

[Magda Zacharska] 10:48:11
So what the architects proposed was to specify that the query will return more than so, and so records when I heard that it brought the memories of the inventor search when in early implementation of inventory where if we had a result of more than 10,000, that could mean 10,000 or 10.001 ro 10 million. So the question is, how important is it to have this information in the preview?

[Magda Zacharska] 10:49:12
Do you need to know at this point how many records match?

[Mark Arnold] 10:49:23
It would be my preference that we did. I do not expect Bulk Edit to be a fast thing. So, waiting for a bit to get the exact number of records for me would not be unexpected and I would prefer to see it. I want to know that the scope of what I'm doing is right.

[Magda Zacharska] 10:49:44
Yeah, I agree with you because it really matters if your query returns 1 million records when you expected 5,000 records. Then you would know something is not as expected and you would adjust the query statement to narrow down.

[Erin Nettifee] 10:50:06
Right. There's agreement. People are agreeing with Mark in the chat. Yeah.

[Magda Zacharska] 10:50:10
Okay, great. The other point that the architects made is if it is important to provide the number, then actually, this preview would be running the query, so we are not gaining anything by previewing 100.

[Erin Nettifee] 10:50:42
Is that specific to users? Or is that a generic thing across FOLIO?

[Magda Zacharska] 10:50:48
No, it's a Postgres issue not just user records type issue.

[Erin Nettifee] 10:50:58
So Thomas brings up the point in chat about whether we might slow FOLIO down or slow down a particular app.

[Erin Nettifee] 10:51:11
If we have a record I think it's more likely to happen.

[Erin Nettifee] 10:51:14
Maybe more likely with inventory than with users. But you know, if we inadvertently start a query, that's gonna pull 40,000 records instead of 400. I don't know if that's a concern

[Ann-Marie Breaux] 10:51:25
I think that's a valid concern.

[Ann-Marie Breaux] 10:51:29
If you started a query accidentally to show me all books...

[Mark Arnold] 10:51:33
But if you use the the API with a limit of 0, it doesn't return all the records?

[Mark Arnold] 10:51:40
It simply returns the number of records that would be returned.

[Mark Arnold] 10:51:43
I guess I don't completely understand what the issue is.

[Mark Arnold] 10:51:46
I mean, I know that when you do an API call with a limit of 0. It does take some time, I mean, it still has to find those records to return the count, but it's not returning those records.

[Erin Nettifee] 10:52:01
Right, but it's still not an easier search to do. It still costs the same. It's just that the return comes back different/

[Mark Arnold] 10:52:08
Sure, but I do it all the time in production during the day when I'm working on another project and another job, and it doesn't cause any problems that anybody's told me about.

[Erin Nettifee] 10:52:19
I think it would be at bigger institutions.

[Magda Zacharska] 10:52:21
So, I want to clarify.  We are talking about the preview. So the question is for the preview. If we want to know how many records will match the query, this is running the query, and we are on the screen when we are previewing 100 records, it's at this point we need to run the query, because we want to know the whole number. So the question is, do we really need to preview?

[Magda Zacharska] 10:53:03
Or should we show all of the records here?

[Erin Nettifee] 10:53:11
I I can't do anything with the records here. So I guess I'm not sure what previewing all 5,600 records here would do for me. But others should definitely chime in.

[Thomas Trutt] 10:53:38
I would tend to agree. I think, showing the first 100 records probably would be enough when you're pulling 5,622 complete records through the AP. I know the back-end query is going to be the same but your response time is going to be a little bit slower, and it's also going to slow down the UI, and that would be my fear is showing off a huge amount of records. And this would really show down the UI for not really any benefit.

[Magda Zacharska] 10:54:07
So we will show the all records. Once you click run query, it will take you to the Bulk Edit landing page where you can paginate through the record set.

[Magda Zacharska] 10:54:26
What will happen behind the scene is that at this point, you are only interacting with a copy of the records stored in a local file. You are not making database calls. So this is how we will address the issue of constantly pulling the database and impacting the performance.

[Thomas Trutt] 10:55:01
I think that makes sense

[Magda Zacharska] 10:55:08
I see Jennifer, asks if there's a download option. Jennifer, is your question about downloading the results or downloading the query?

[Jennifer Eustis (she/her)] 10:55:22
I know when you search on the identifier we can download the matched records before you do anything. I was wondering if there was something similar here.

[Magda Zacharska] 10:55:37
Yes, yes. So the functionality that exists for identifiers will be supported for query results as well.

[Jennifer Eustis (she/her)] 10:55:47
Okay. So I, I think, having just a preview of like the first 100 or so records is fine, because we have that download option.

[Jennifer Eustis (she/her)] 10:55:57
So if you have like, 10,000 or however many, then you can download the complete set of matched records to really comb through those.

[Magda Zacharska] 10:56:07
But you will not have all the records when you are on the preview screen. You will only have this option after you run the query, and are in Bulk Edit.

[Magda Zacharska] 10:56:27
Let me find the mockup so what I'm talking about is clear.

[Magda Zacharska] 10:56:57
So this is the screen we are talking about right now, then.

[Magda Zacharska] 10:57:01
So when we test the query we are at this point seeing a preview of 100 records.

Open

[Magda Zacharska] 10:57:16
The the user clicks run query and the progress bar probably appears because we already have the file.

Open

[Magda Zacharska] 10:57:28
And the we are at the Bulk Edit form the landing page.

Open

[Magda Zacharska] 10:57:37
Here are the records. You can paginate, but you also have the download records in CSV format.

[Magda Zacharska] 10:58:06
So we agree that the query should return the exact match of records is important, and we definitely need that.

[Magda Zacharska] 10:58:24
Thank you for this, and we have 2 min left.

[Magda Zacharska] 10:58:29
We will not be able to cover the query examples.

[Magda Zacharska] 10:58:35
I just one that to point to that I started creating a JIRA with a list of possible searches by the record type and property type.

Open

[Magda Zacharska] 10:58:54
This is how the how we are going to develop the tool.

[Magda Zacharska] 11:00:18
Please take a look at this document, and we will start our next meeting by talking about those searches.

[Magda Zacharska] 11:00:28
If you have any comments, please let me know in the meantime.

[Magda Zacharska] 11:00:33
Thank you all for your time and your feedback and I'll see you in 2 weeks.

[Magda Zacharska] 11:00:40
Thank you.

Chat

00:03:07 Amanda Ros (she/her): still coughing from being sick so I'll only be "talking" in chat today. 00:03:30 Jennifer Eustis (she/her): Hope you get better soon Amanda 00:03:51 Amanda Ros (she/her): thanks 00:04:25 Erin Nettifee: agenda link: https://wiki.folio.org/display/BULKEDIT/2023-1-10+Bulk+Edit+Working+Group+Meeting+Notes 00:06:04 Amanda Ros (she/her): yes 00:10:15 Erin Nettifee: https://issues.folio.org/browse/UXPROD-3469 00:14:15 Leeda Adkins: A common use case for my team is bulk edits from Missing to Lost. A status change to Missing or to Withdrawn is done manually. 00:15:37 Jenn Colt: And that one can get updated without check in? 00:16:12 Jenn Colt: Thanks! 00:22:09 Leeda Adkins: BRB 00:24:22 Leeda Adkins: back 00:30:39 Amanda Ros (she/her): have to run to another meeting 00:34:15 Jennifer Eustis (she/her): +1 to adding it to the documentation 00:41:46 Kimie (Keemee) Kester: If the dots are animating then it won’t look stuck 00:42:10 Jennifer Eustis (she/her): +1 to the dots 00:42:14 Lisa Smith, Mich State: I would like seeing the number of records processed 00:42:31 Lynne Fors: +1 Lisa 00:44:00 Leeda Adkins: I like the idea of exposing the count as well 00:50:59 Jennifer Eustis (she/her): I would prefer to have the total number of records. 00:51:09 Lynne Fors: I agree with Mark and Jennifer 00:51:22 Leeda Adkins: Agreed as well 00:51:40 Thomas Trutt: would it cause a performance issue with the rest of the system? 00:55:40 Jennifer Eustis (she/her): Is there a download option with the query search? 00:58:01 Leeda Adkins: That sounds good, having the download available once you run the query