Page Comparison

• 10:08:40 Magda: Development status. We have progressed nicely and added one of the things that you requested on the bulk edit Bulk Edit capabilities when you are doing the in-app updates.
• 10:09:54 Magda: In the in-app approach, as you add actions to be performed, the drop-down options narrow dynamically based on prior selections. You can see that your feedback was incorporated into our work.

• 10:10:24 Magda: The scram board--we already passed the deadline for new development for Morning Glory. So for the next several sprints, we will be working on bugs. There are bugs we would like to address.
• 10:10:45 Magda: So you can. you can see the scrum board is full.

We need to push UAT one sprint later as MODEXPW-145 and UIBULKED-100 affect how the Are you sure and Confirmation form report updated records

• 10:10:50 Magda: The things that contributed to the delay of the user acceptance testing are on the board as well. First of all the matched records label cleanup. The "are you sure" and "number of affected records" were mixed up and confusing. So this needs to be cleaned up because it will at this point not provide enough information and will be more confusing

• 10:10:52 Magda: And then there is a work on the back end with the "preview of the API upgrading." This means that work on the "are you sure form" when there are no affected records displaying as empty needs to be addressed as well.

• 10:12:11 Magda: If you look at those 2 tickets that are also linked on our agenda, and you scroll down I added to one additional user story that has a recording of undesired behavior. So. if you really would like to drill down on the behavior here's all the information if have any comments.

• 10:13:05 Magda: There is one more thing regarding the user acceptance testing. The same environment is being used for performance testing. We noticed that the performance of the Users App is quick, even on 80,000 or 90,000 users that are in our bulk edit Bulk Edit environment. However, if we do the item updates on the more than 8 million records, the performance is not that great?
• 10:13:45 Magda: So we would like. The original plan was to do the performance testing after a user acceptance test but then this would shorten the time to address performance issues. So, delaying user acceptance testing will give us time to investigate performance now and work on the improvements while the user acceptance happens.10:14:32 Magda: The next items that I would like to cover are the features that I would like us to work on in Nolana.

UXPROD-3230 - Bulk delete user records

UXPROD-3705 - Bulk Edit - User data - in app approach

UXPROD-3704 - Bulk Edit - in app approach - holdings locations

UXPROD-3706 -  Bulk delete inventory item records

UXPROD-3707 - Bulk edit - inventory items - csv approach

• 10:14:32 Magda: The next items that I would like to cover are the features that I would like us to work on in Nolana. However, I have some questions for this group and also to provide you with additional information.
• 10:15:02 Magda: Let's start with deleting user records. This is something we discussed, I think partially last meeting. I followed up with the User SIF and also with some subject matter experts that  were not present during the meeting. And this is what we came up with,

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-3230

  .
• 10:16:20 Magda: So the first thing that I will start is what is outside the scope. Soft delete is outside the scope. The reason for this is when we do the bulk edit Bulk Edit functionality, we use the existing API's. and soft delete is not implemented on user records. It's not even implemented anywhere in yet in FOLIO. It would actually require a platform-wide conversation. So we would implement the bulk edit Bulk Edit delete the way it is for single records in user. This means references to circulation transactions will be handled because this is what is happening on the single record delete. However, all the shortcomings of the implementation will be present as well.
• 10:17:26 Magda: So, for example, if we delete a user that is referenced somewhere in the metadata, let's say in inventory the metadata says this record was updated by Magda Zacharska. Then, let's say we deleted Magda's record from Users. Then, when you open the inventory record, you will see that the record was updated by an "unknown" user.
• 10:18:02 Erin: That was just fixed by Dennis Bridges team, I think. I'll send you the Jira Magda.
• 10:18:25 Magda: I am aware of this but do send me the Jira. I doubt this is how it was implemented.
• 10:18:27 Erin: There was a gap in how it was done.
• 10:18:27 Magda: The other problem with the existing implementation of the delete users is that it deletes the user record, but it does not delete references from the permissions table. So you will have abandoned records. It does not cause any harm besides growing data, you have the entries in the permission tables that refer to non-existing users.
• 10:19:20 Erin: So what remains in the permissions table is the UUID for the user, but you don't have the name anymore. If we deleted your account, whatever UUID you had would remain in the permissions users area. But you wouldn't be able to look up the UUID  to find the user's name.
• 10:20:33 Sara: Okay, but would I be able to use that UUID without a name and see what changes did this UUID make in inventory, for example?
• 10:20:49 Erin: I don't know.
• Sara: Because that could be of interest if I have a user who leaves and later we discover they made lots of errors, and we're trying to track down all the errors to fix them. Then it could be irrespective of the name irrelevant but the UUID is still everywhere.
• 10:21:16 Magda: I think I think this is a good point. So does it mean that this is a desirable behavior?
• 10:21:29 Sara: I've definitely had to use the username of somebody who's done lots of work, and I needed to find all their work to verify that it was done correctly after they left.
• 10:22:02 Erin: But what you should do in that scenario is deactivate that user, but keep their record until you have validated everything and then delete the user. The answer isn't to trace the UUID.
• 10:22:15 Sara: Well, maybe not. But maybe iI'm not the one who deleted the user. And then later, we figure it out. I'm just wondering. And I'm wondering also in connection with acquisitions and this just came up. So do if if a user, If my name was associated with an order because I requested that thing to be ordered, what happens there?

• Does it also turn into

• an unknown user?
• 10:22:48 Magda: I do believe that the orders are being covered.No, actually...
• 10:22:

• 59: Erin: Requesting is one of the dependency checks

• that happens with the user

• deletes.
• 10:22:59

• Sara: Not request in the sense of

• requests, but there's a field

• called or selector

• or

• requestor in the order

• where you can mark that somebody asks for something to be ordered.
• 10:23

• :27 Erin: That's just a straight-up text field that has no connection to a user record. So deleting a user wouldn't do anything to this field.
• 10:23

• :29: Sara: Okay,

• great thanks.
• 10:23:38 Magda: So I

• would like to move to another

• feature as well.

• And just a quick note

• . I'm meeting with the

• User SIG tomorrow again to discuss this implementation, and get their final blessing for the approach or not.

• In any case, for now, it is planned for

• Nolana. If rejected by

• the SIG, we will discuss this probably later.

• 10:23:39 Magda: The next user feature is about the in-app approach for user records

• . As you recall

• , at the end of

• Morning Glory, user records

• can only be deleted

• through the CSV approach, meaning the user will download the

• CSV file with the matching records and make the change locally and upload the

• CSV. As you also may recall,

• there was

• user testing done in

• the early months of this year, and it was stated by the community that

• the preferred way of doing

• Bulk Edit is

• with the in-app approach. To meet this expectation

• we will be adding this functionality for user records as well.
• 10:25:20 Magda: So at the end of the

• Nolana, the user records

• in the in-app approach will support changes

10:25:52 For example, those 3 kids were not selective I'm only Thomas, can you, mute?

10:26:02 I think that might be coming from you background. sorry about that that's okay, Thanks.

10:26:09 And at some point I review all the fields on the user records.

• to the patron group, expiration date, and the email address. Those fields were not selected randomly. I reviewed all of the user records fields with the User Management SIG and we come up with

• priorities

• for the fields.

• All those that are marked as 0 "must-have,

• " will be addressed

• right now, with the exception of permissions

• which are a separate

• record group

• and will be addressed in later releases.
• 10:26:46 Magda: And I do believe that in my out of scope, I specified that this

• is planted for the Orchid release, which is the next

• release after Nolana.

Image Added

• 10:27:14 Magda: The next one on the list is the

• holding's location. And I think it's clear we need this.

• We did similar work for the

• item

• 's location and it is straightforward. This definitely would be implemented in

• the scope of

• Nolana.
• 10:27:37 Magda: The next one is deleting item records

• which makes me a little bit nervous. And I would like to hear from this group

• your take on

• this.
• 10:27:54

• Erin: Deleting records just makes you nervous?
• 10:27:54 Magda: Yes.
• 10:28:04 Erin: I understand that. I definitely think it's needed.

• I think we would want to spend time talking to Metadata management

• and Charlotte.
• 10:28:14 Magda: So again

• , the bulk Delete uses the existing

• APIs. So whatever is done on the inventory

• side will be brought in...
• 10:28:30

• Erin: Jennifer is commenting in the chat that right now

• Metadata

• Management is doing a lot of work

• on an instance deletion and gathering those use cases. Because we've implemented item delete already

• , then maybe there's not a ton of conversation or maybe the people here from Metadata

• Management can go back to that working group and say,

• hey, this is coming

• , is there anything you want us to make sure that we talk about or that

• you're concerned

• about? And so maybe that's enough. I guess I just feel like having that conversation might ameliorate any worries that we might be implementing functionality that isn't desired.
• 10:29:13

• Magda: I know it

• is desired functionality because I have

• another spreadsheet that is based on

• use cases provided by the community and I will share this

• shortly as

• well. But my concern about the

• deletion of

• items right now is that the functionality

• and dependencies are handled in the

• UI, and I see

• John stated that this is true, meaning

• we have this on the Ui.

• That means if we call

• APIs we are deleting everything, causing

• a lot of damage

• , which we obviously don't want to

• do

• . If we need to implement this on the back end, then it

• significantly increases the scope of the work.
• 10:30:

• 29 Erin: I see Sarah

• 's hand up. I'm curious to hear what you think.
• 10:30:29

• Sara: It's interesting because this morning this came up

• as a topic to me.

• We have rows and rows and rows of stack

• shelves that we want to weed, and we don't have the time right now physically

• take that on.  On the other hand, if

• my one

• instance record has 1,668 items attached to it, and that's just one of the things that we want to weed

• , if I wait till

• FOLIO that

• will be an individual

• item by item by item, deletion, right right now,

• Erin, right?

• And there is no way in inventory for me to just say, check all of these off and delete all of them, because I've just weed them.

• So I am debating for 10 to 20 such cases

• whether to

• do this in my old system

• where I can

• just do a total delete with one push of the button and just leave them on the shelves, and then just make myself a

• huge note, saying,

• don't forget

• to remove them from the shelves, and put them in the

• garbage

• at some point in the future.

• Do you see my dilemma like if I wait?

• What am I gonna do?
• 10:32:05 Erin: it's not a great answer. But it is pretty trivial to script it.
• 10:32:05 Magda: In fact, yes.

• But if you script this, Erin, this would be exactly the same case

• we are facing right now

• that everything

• will be deleted.
• 10:32:

• 25 Erin: You have to check the dependencies manually.

• But then if you were

• absolutely ready to get rid of these 1,500 records that

• is pretty easy to do with

• a python script.
• 10:32:34

• Sara: Yeah, through the APIs. So again, though, this all relies on

• the access to that

• , the ability to do that, and so forth

• .
• 10:32:49 Erin: Sure that's

• why I said

• it's not a great answer

• , but there is a

• way to do it.
• 10:32:53

• Sara: But eventually I don't think this is how we want to

• have to do

• this.
• 10:33:03

• Erin: And that's exactly what

• Magda is outlining in

• this Jira some of the challenges that we'll be involved in getting there.

• It looks like Jackie has her hand up.
• 10:33:17 Jackie: I do.

• I would say

• I'm on the other end of what Sarah is describing, and Jen can speak to this

• too

• . We were required to do a mass withdrawal project after

• implementation, and I don't know how difficult it was for the batch processing office to take care of the records that were so huge that we couldn't manually delete them.

• But we had staff sitting here deleting hundreds of records manually, and it was

• awful. If we can have a solution to that I would be very happy. I don't know if that's a constructive comment.
• 10:33:55

• Magda: It is. And all the comments are constructive. I just see we need to

• implement the dependencies that are currently in the

• UI on the back end.

• I also believe that not all the dependencies that are implemented

• on the UI cover all use cases for

• deletion. So, this one

• requires additional research

• .
• 10:34:

• 49 Bob: For us, deletion across the system, of various record types, is a very high priority. I have a hard time understanding why this

• isn't a very high priority, as in most current systems you can delete records.

• I mean this is just gonna be this is a big problem for us.

• We're always

• deleting things out of

• our current system.
• 10:35:10 Magda: This is really good. If you can add

• ranking to this

• ticket, that would be helpful

• , and I will follow up with

• the Metadata Management SIG to talk about the dependencies and what we need to implement to make it

• work. I see

• that there is a huge need for this.

• 10:35:47

• Erin: So Nolana so far is bulk deleting inventory items, users in-app approach, and then is that it, or is there other stuff in

• Nolana?
• 10:36:06

• Magda: This is Nolana.

  • UXPROD-3230 - Bulk delete user records

    UXPROD-3705 - Bulk Edit - User data - in app approach

    UXPROD-3704 - Bulk Edit - in app approach - holdings locations

    UXPROD-3706 -  Bulk delete inventory item records

    UXPROD-3707 - Bulk edit - inventory items - csv approach

• 10:36:13 Magda: The last one, Bulk Edit inventory items using the CSV approach. This is the

• most controversial from my point of view, and I would like to hear your feedback on this.
• 10:36:21

10:36:33 Okay, So this is I didn't want it to do this but okay,

• Magda: This is in draft, and the behavior will be exactly the same as we do with the user records

• right now. So we are identifying records

• based on submitted identifiers

• , then saving records to the

• CSV file, the user makes the changes locally and then

10:37:25 Hmm,

10:37:26 Hmm. and the system updates every field at E as it was specified in the in the Csv.

• uploads the file, and the system updates every field specified in the CSV. The reason I think it is

• controversial is because of the dependencies.

• What we are going to do. We are going to

• get the CSV file and put the records as they are specified in the data.

• Obviously, there will be all these steps that are in the user records update

• when we are asking you to

• "are you sure" you want to do this?

• You

• can also revert your

• changes by

• resending the original file.
• 10:38:29

• Erin: I have a question. Do item records have optimistic locking at this point

• ?
•  10:38:43 Magda: They do. But I don't think optimistic looking will prevent someone to make a change in loan types

• , for example, that will affect the behavior, or will change the status for the record

• that is in order, for example, or something like that. The

• CSV approach relies heavily on the knowledge of people who do

• Bulk Editing. We can limit access to this functionality

• through permission so only selected users will have access to it.

• But it's an extremely powerful

• tool.

• You can do whatever you want on the record.

• But you need to know the consequences of your actions.
• 10:39:31 Erin: Optimistic locking should stop it if like let's say, for example, I downloaded a 100 items and I was working on the

• CSV file, and during the time I was working on the

• CSV file 5 of those items were

• checked out

• . That changed in the item status should increment the record version.

• So I should get an error when I post that record back.
• 10:39:56

• Magda: Yes, so optimistic locking will work only if the change occurred

• in the meantime

10:40:06 On. If the record was set in transit yesterday, you get the file today and change the status for it.

10:40:18 For example. Oh, no, in transit maybe it's not very good Let's say the status is paged the status is page.

• . But let's say the status is paged. You downloaded the file this morning, and in the afternoon the status is still page, and you are

• changing the status to available

• . Optimistic locking is not going to prevent

• you from doing it.
• 10:40:41 Erin: It Should.

• You are making another change.
• Magda:  There was no change. This is another update.

• Optimistic locking is not looking at the values. Optimistic locking is only checking the version.

• Erin: I guess I would assume that the version that you have is like version 20 and when you downloaded it, the versions matched But then when the

• status changed in inventory

• , became version 21, and then at that point the versions don't match, and so I shouldn't be able to post that record back to inventory.
• 10:41:29 Magda: Why would they

• not match?

• Erin: Because of the change of the status

• in inventory

• while I was working on the

• CSV.

• Magda:

• I created a file this morning, and let's say the version of the record was 30.

• There were no changes

• in the record. The record was paged all the time

• . I make the changes locally, and a couple of hours later I'm: uploading my file.

• So, this is a new version, and overwriting the page

• with available. The version status changes to 31. Optimistic locking would work only if I had version 30, someone in the meantime, in the system

• changed the status to

• awaiting pickup,  and so then that would change the

• version in optimistic locking, and my override would not work because I had the older version.

• But if the record has not

• changed in the meantime, nothing will prevent me from changing the record that was page to be available.
• 10:42:50 Erin: I see what you mean.
• Magda: I see a lot of conversation in chat,

• can someone speak up and say what they are typing

• .
• 10:43:07 Erin: There's only one real question in here it's from

• Sara who says that the in-app approach for item records is locations and statuses, and she's asking about whether in-app is supporting loan type for item records.
• 10:43:18

• Magda: No. This is actually on my list of things to do because we were talking about

• loan types at some point

• and decided this is

• dangerous territory, and we don't want to

• venture there

• yet. But if we go with the

• CSV approach

• , the user will be able

• to change the

• loan type anyway.

• And when I look at my spreadsheet

• of the most frequently requested fields

10:43:56 It's not pretty, but it has a lot of information well helpful for me.

10:44:03 So what I did. can you read it? or, should I change the a bit bigger?

10:44:10 Would help. Okay, So what what I did? I would to all use cases that we had for bulk edit.

• ...what I did was go through all use cases that we had for Bulk Edit noting what changes were requested for each record type.

• When I look at the item record

• , the areas that were mentioned

• are: statistical codes

• , tags, discovery

• suppress, URLs, delete, status (item), call number types/prefix/copy number, and loan types.

Image Added

• 10:44:49

• Magda: I'm wondering if it would make sense,  instead of investing time into the CSV approach, to add those missing fields to the Inventory in-app approach.

• 10:45:50 Erin: So what you are saying is that doing the CSV approach next would address the things that are listed here.

  10:45

10:45:18 But, So the call number types, prefixes, numbers, and long types.

10:45:27 I'm wondering if the if it would make sense instead of investing time into the Csv.

10:45:39 Approach. good! those missing fields to inventory in our approach

10:45:50 So you're saying that the the doing the csv approach next would address the things that are listed here.

10:45:59 Yes, but in addition to others, and i'm just concerned that we are opening a account of forms.

10:46:11 I mean I think you'll find that any library can come up with a use case for editing a field on the item record needed to do it in bulk.

10:46:18 My concern would be that there are things that are inherited on the item record that you wouldn't want to necessarily edit, because you don't wanna mess with business logic right like things like item effective location.

10:46:32 You don't want to accept that but if it's a field that is directly on the item.

10:46:40 Why not be able to edit it having a Do we have anyone from the Mmc. chiming in?

10:46:51 Let me check the the chat. Jen, I see your comments.

10:46:58 Can you? What do you think people should look like guilty Well, that's that's you can ignore that. That's just me. ?

10:47:06 And Jackie time. my , my most recent one was just agreeing that the so it for the result, it's a whole process.

10:47:13 We need to change the location. The temporary looks and the temporary loan type they can only do half of that.

10:47:23 They're still gonna have to come to us and get it finished.

10:47:25 So basically you're saying the location without long time. types don't really work for for the most I mean the reserves are just such a common umhm it's you know it's like 2 or

10:47:41 3 times a year for multiple We have to do it.

10:47:47 So , like 3 times per year i'm gonna have to do this for 4 libraries, right? like that, I can predict Jen.

10:48:00 And what are the implications of changing the long type so It's just a temporary one, So it's a very.

10:48:09 It's very low also so I guess as long as we're not deleting my feeling about a lot of these is you've given it a list of ids and told it a change to make if you change your

10:48:21 mind, you can give it the list of ids again and change it back.

10:48:25 So for me it feels low risk that's all right all that loan type is gonna do.

10:48:34 Is it's gonna influence the potentially influence a circle right? So if I change a loan type, it may mean that a different circulation rolled after it's not gonna you're not messing with data integrity in that sense you're

10:48:46 not you know you're not risking losing information necessarily

10:48:54 So you are saying we should concentrate on temporary loan types.

10:49:01 You would want to be able to do both permanent and temporary.

10:49:06 The temporary just happens more often. Okay, let alone.

10:49:11 I mean at least in my experience alone type doesn't change it's.

10:49:16 It's. Sometimes something goes into in or out of like a special collection and that'll that'll be to be on changes.

10:49:22 But but that's a lot less often but it's also.

10:49:27 We have used cases at Duke, for for example, making things on circulating and circulating again, and we would use loan type for that.

10:49:34 And you know if you're doing that for a year you're gonna change the permanent loan type.

10:49:39 How could change on the long time depend on the item status?

10:49:46 But would you? If something is checked out, for example, you can change the loan type on.

10:49:53 I checked out Item. and this is a design behavior all it it doesn't influence the active loan.

10:50:03 What would happen is, if the person chose to renew the item, they might get a different circle the next time.

10:50:13 So you know, if I have a an item where my certain my loan type is standard loan, and I need that thing to be a course reserve. and I change the loan type from standard loan to course reserve that may mean that that patron

10:50:24 can't renew that item and that's desired right because I want that thing to come back.

10:50:32 So I mean there's something people need to understand the implication.

10:50:35 But it's not you're not hurting things there and you don't need to build in a particular guard rail.

10:50:42 In my opinion, and unfortunately I have to drop off for my next meeting.

10:50:49 So . you think? Thank you. And I seen chat hey! come on or agree with the Aaron suggestion.

10:51:04 So I won't follow up I The item check and check out.

10:51:12 Note sometimes goes hand in hand with these types of things. So, for example, we do a lot of displays, and so we have.

10:51:20 The temporary location gets changed to on display that may or may so require us to change the the loan type.

10:51:29 If we're making that display non time right and then we usually have a check-in checkout type.

10:51:36 Note especially, so that when the thing it it's dropped off at the counter, and because somebody's looked at it and then left it lying somewhere right and not put it back on display Then it immediately pops up as for

10:51:52 the circulation person. Oh, this goes on display right now, right like so it's a help with that, And sometimes you can borrow the things that are on display.

10:52:04 So then the check-in check out note saying, Oh, if it comes back, put it back on display.

10:52:08 It is really helpful, and and that would have no dependencies that would be totally item dependent and totally relevant for anything else to check.

10:52:21 Just going back to what I think Aaron was saying earlier, that you know these things are just really.

10:52:25 Item and why shouldn't we be able to change them okay.

10:52:32 Just mine, too. I will follow up So basically we have 2 options.

10:52:38 One. Add to the list of properties that are supported in in app approach or spend time on the Cse approach for items.

10:52:55 And how this group fields, what would be more beneficial?

10:53:03 Additional fields in enough approach, or all fields in Csv.

10:53:08 Approach. Yeah, how do you? How do you? how this group feels?

10:53:22 And they want please. I'm Sorry jen what Did you say that my vote is for Csv.

10:53:36 And out there I can see the benefit of the Csv.

10:53:41 Really, truly, Yes, and and obviously there are a lot of things there that have to become that way because of the dependencies.

10:53:49 I guess you know that it will just make it easier.

10:53:50 But I think that there are also a lot of things that are have are irrelevant for dependencies like the check-in checkout.

10:54:01 No, For example, then users who do not necessarily have the permissions to do the Cse version.

10:54:11 Can take care of an app , and I think there's a benefit to letting people do their job.

10:54:18 To the best that they can, right or to the fullest that they can, and and by making everything so the more difficult way, or the more permission heavy way, is a barrier.

10:54:39 Yeah. but then so, Sarah, are you saying that you want to have more in app approach?

10:54:45 So I want everything right

10:54:50 I know I can give you everything in the next 10 years.

10:54:57 Yeah, I know So I guess I wouldn't I guess what i'm saying to a certain extent is, if if certain things can be it, I understand that you need to weigh what is , if something like book editing the

10:55:22 check-in check out note in app was not a difficult thing to do.

10:55:28 Then it would be really nice to have sooner rather than later.

10:55:31 , I I guess, to to allow for the different things.

10:55:35 But if if everything has to go towards the csv because that's what then?

10:55:42 Yes, of course, that's what I have to admit that I am surprised that I get so many comes up for Csv because I was expecting I will get a push back from from from from this group.

10:56:01 So thank you very much. Put to speak back and for the long run, obviously we would like to do the enough approach to make it easier for the users.

10:56:13 But we are facing. Give you something or give you something.

10:56:18 And Csv is the approach. that we can do this faster, but we put a lot of responsibility on on the users.

10:56:28 However, as I said before, and I think John repeated it.

10:56:33 The changes that i'm being made with csv can be This is that re updated by submitting the file again.

10:56:43 But I will follow up with the Mmc.

10:56:48 1 one more time, and to make sure I was talk to them about the shan of items, and we'll bring it to Csv. Mentioning that this group strongly supports Csv Approach Thank you.

10:57:06 Very much. We have 3 min left, and I would like to use those 3 min for the this.

10:57:14 Follow up from the discussion that we had in slack regarding the suppression.

10:57:20 And this is what Jennifer mentioned, and I do believe that this should be implemented first on the inventory for one record.

10:57:34 So once you suppress the record on the instance, level it automatically.

10:57:42 Should be holdings and items. This is Karen not implemented on the inventory.

10:57:51 And my question basic question to this group is, Do you think this is just bulk edit, specific functionality?

10:58:05 Or this is the functionality that you would like to have in inventory as well

10:58:19 This is jennifer x I think i'd like to see it on on inventory.

10:58:24 I mean if you are doing it at that level of you know the instance. it's it's kind of the top level.

10:58:31 You know whether or not you have an underlying, you know, Mark Srs.

10:58:36 I mean in that case you're suppressing everything from discovery.

10:58:41 So it makes sense to you know suppress everything I mean i'll bring it down so to the and i'm sick as well to to Get that.

10:58:56 Feedback, and if this is implemented on the inventory, then we can reuse it very easily for the bulk edit as well.

10:59:04 I do have one use case where this is not a good idea, though.

10:59:11 I am in the process of suppressing a bunch of records in a collection that we're moving, and

10:59:28 In some case it gives, some of the records will be unsuppressed in the future, because some were keeping in some or not.

10:59:36 , I'm. not going to know which records were which holdings and items records were suppressed previous to my having 6.

10:59:51 The instance record. So if I suppress the instance records in it, suppresses everything underneath it.

10:59:59 But then, when I unsuppress, what needs to get unsuppressed apps, the item and holdings level

11:00:12 This can get complicated. And how are you using those suppression?

11:00:18 Is this for or is this for something else? We have a collection that we are in the process of withdrawing a large percentage of the collection, but not all of it.

11:00:32 2 facilitate that right now we are simply suppressing everything in the collection.

11:00:41 And then we will go back and unsuppress.

11:00:44 The problem is I mean it's the problem i'm running into now is that some of the titles also have holdings outside of this collection.

11:00:58 So. In that case actually I can't suppress the instance record.

11:01:05 I can only suppress the holdings record, so maybe this is I mean, maybe this is a moot point, but I can see instances where you're going to suppress an instance record, and then you're going to turn it back on later.

11:01:18 On. but now everything underneath it's suppressed and you don't know what was previously suppressed, and what was suppressed as part of suppressing the instance and Yes, and I think there is also a question of

11:01:33 what will happen if you to the suppress suppress instance, you add a new holding holding soup.

11:01:40 Would you assume that it will be suppressed automatically as well or not?

11:01:48 And the same for items in so i'm doing this of course, by script right now.

11:01:54 , But no, I am not suppressing the holdings, because eventually most of those holdings will be withdrawn, and they will get suppressed as part of that process.

11:02:06 But when I go back and unsuppress the records that we're going to keep, I don't want to have to unsuppress the holdings records, so in my case I only want to suppress

11:02:18 let's see the instance records I'm.

11:02:23 Sorry I have to run to another meeting. we will believe we will continue this conversation.

11:02:30 The suppression conversation during that, and then sick meeting. If I get on their schedule this week or next week, we still have the permissions.

11:02:40 For the expert manager. We will talk about this, and and next time, and the Jennifer.

11:02:48 I saw your comment about the bug edits and looked at the item statuses and inventory.

11:02:58 I need to. There is this: There are a couple of statuses that are currently not supported by bucketed.

11:03:05 I will need to take a closer look at the implication of it and notification if needed.

11:03:10 We will add this in a Nolana as a supported, additionally supported status.

11:03:23 But this requires some work on my side first I also have another meeting. I'm.

11:03:25 All of the late for it have to run i'll see you in 2 weeks 30 min late, and then normally I will post this on the channel.

11:03:35 Thanks again for your feedback. have a good rest of your day, Thanksgiving.

11:03:40 Bye,

11:04:03 And I don't know how to leave the meeting

• :59 Magda: Yes, but in addition to others, and I'm just concerned that we are opening a can of worms.

• 10:46:11 Erin: I mean I think you'll find that any library can come up with a use case for editing a field on the item record and need to do it in bulk. My concern would be that there are things that are inherited on the item record that you wouldn't want to necessarily edit because you don't wanna mess with business logic. Things like item effective location. You don't want to set that but if it's a field that is directly on the item. Why not be able to edit it.

• Magda: Do we have anyone from the MM SIG to chime in? Let me check the chat. Jen, I see your comments.

• Jen: My most recent chat comment was just agreeing that for reserves it is a whole process. We need to change the temporary location, and the temporary loan type, they can only do half of that. They're still gonna have to come to us and get it finished.

• 10:47:25 Magda: So basically you're saying the location without loan types doesn't really work.

•  Jen: I mean the reserves are just such a common thing, it's you know it's like 2 or 3 times a year for multiple libraries we have to do it.

•  10:47:47 Erin: There are absolutely use cases for just changing locations.
• Jen: Yes, they are just less...So, like 3 times per year, I'm gonna have to do this for 4 libraries, right? I can predict it.
• Magda: Jen, what are the implications of changing the loan type It's just a temporary one, So it's very low. Also, as long as we are not deleting, my feeling about a lot of these is you've given it a list of IDs, and you have told it to make the changes, if you change your mind, you can give it the list of IDs again and change it back. So for me, it feels low risk.
• 10:48:25 Erin: All that a loan type is gonna do is potentially influence a circ rule. If I change a loan type, It's not messing with data integrity in that sense you're not you know you're not risking losing information necessarily.
• Magda: So you are saying we should concentrate on temporary loan types?

• Erin: You would want to be able to do both permanent and temporary.

• 10:49:06 Jen: The temporary just happens more often. I mean at least in my experience loan type doesn't change. Sometimes something goes into or out of a special collection and that'll be a field that changes. But that's a lot less often.

• Erin: But we have used cases at Duke, for example, making things non-circulating and circulating again, and we would use loan type for that. And you know if you're doing that for a year you're gonna change the permanent loan type.

• 10:49:39 Magda: How could change on the loan type change the item status?

• 10:49:46 Erin: It doesn't But would you? If something is checked out, for example?
• Erin: You can change the loan type on a checked-out Item.
• Magda: And this is a design behavior?
• Erin: It could be. It doesn't influence the active loan. What would happen is, that if the person chose to renew the item, they might get a different circ rule. So you know, if I have an item where my loan type is a standard loan, and I need that thing to be a course reserve, and I change the loan type from standard loan to course reserve then that may mean that the patron cannot renew that item and that's desired right because I want that thing to come back. So I mean there's something people need to understand the implication. But it's not hurting things there and you don't need to build in a particular guard rail In my opinion. Unfortunately, I have to drop off for my next meeting.
• 10:50:49 Magda: And I see in chat that Sara is in agreement with Erin's suggestion.
• 10:51:04 Sara: Sometimes check-in/out notes go hand in hand with these types of things. So, for example, we do a lot of displays, and so we have the temporary location that gets changed to "on display" and that may or may so require us to change the loan type if we're making that display non-circ for a period of time and then we usually have a check-in checkout note to alert staff to place the item back on display if it is dropped off at the counter, and because somebody's looked at it and then left it lying somewhere right and did not put it back on display. 10:52:08 It is really helpful, and that would have no dependencies. Just going back to what I think Erin was saying earlier, you know these things are just really items and why shouldn't we be able to change them.
•  10:52:38 Magda: I will follow up. We have two options. One. Add to the list of properties that are supported in the in-app approach or spend time on the CSV approach for items. How does this group feel would be more beneficial? Additional fields in the in-app approach, or all fields in CSV approach?
• Jen: My vote is for CSV.
• Sara: I can see the benefit of the CSV really, truly, Yes, and obviously there are a lot of things there that have to be done that way because the dependencies will just make it easier. But I think that there are also a lot of things that are irrelevant for dependencies like the check-in checkout, for example, then users who do not necessarily have the permissions to do the CSV version can take care of in-app, and I think there's a benefit to letting people do their job. And making everything more permission-heavy is a barrier.
• 10:54:39 Magda: So, Sarah, are you saying that you want to have a more in-app approach?
• 10:54:45 So I want everything right. I realize you have to prioritize. If certain things can easily like for example editing the check-in check-out note in-app then it would be really nice to have it sooner rather than later. But if everything has to go towards the CSV because that's what gets it done, then yes, of course, that's what...
• Magda: I have to admit that I am surprised that I get so many thumbs up for CSV because I was expecting I would get a push back from this group. So thank you very much for this feedback. In the long run, obviously, we would like to do the in-app approach to make it easier for the users. But we are facing the question of giving you something or giving you nothing and the CSV approach can be done faster but it puts a lot of responsibility on the users. However, as I said before, and I think Jenn repeated it, the changes that are being made with CSV can be reversed by submitting the file again. But I will follow up with the MM SIG one more time, and to make sure I was talking to them about the deletion of items and will mention that this group strongly supports the CSV approach.