Page Comparison

...

Magda Zacharska (OLD ACCOUNT) Erin Nettifee leeda.adkins@duke.edu Jennifer Eustis Kimie Kester Sara Colglazier Tim Dannay Christine Tobias Robert Scheier

Note Taker:

Robert Scheier

...

Topic

Notes

Housekeeping

10:04:20 Magda: Please add your name to the list of participants.
10:04:37 Magda: The good news is that we have a group of volunteers for the documentation. Aaron, do you want to say something about it?
10:04:50 Erin: Yeah, just thanks to Bob, and Amanda who agreed to help out. I sent a chat message this morning about the initial planning, and also thanks to Christine. Christine and I are working together and hopefully, we'll be able to make it happen by the end of July.
10:05:15 Magda: The next agenda item is the meeting on June 28. Unfortunately, we will need to postpone user acceptance testing for 2 weeks. I would like to start with the kickoff meeting at our regular meeting. I would like us to spend the time to walk through the steps required for user acceptance testing and more about that. We will start the meeting on the 28th 30 minutes later. I will post the information on the channel the day before the meeting as well.
10:06:58 Magda: The last housekeeping item, there will be a bulk edit Bulk Edit working session during WOLFCON. It is planned for August 31st. It's Wednesday at 9:30 am Eastern Time, 3:30 European Time. This will be a hybrid session.
10:08:22 Magda: So, those who cannot be physically in Hamburg will be able to join remotely more about this probably be closer to the event.

Development updates

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.

User Acceptance Testing: June 28- July 12

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.

Nolana features review

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. 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 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 a 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 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 to the patron group, expiration date, and the email address. Those fileds 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.

10:27:14 Magda: The next one on the list is the holding's location. And I think it's clear we need this and we . 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 I 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 's is pretty easy to do with , like 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 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 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 for based on submitted identifiers, then saving records to the CSV file, the user makes the changes locally and then 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 the bulk editingBulk 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 change 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. 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...what I did was go through all use cases that we had for bulk edit 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.

10:44:49 Magda: Im 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: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 chim chime in? Let me check the 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 absolutily absolutely use cases for just chaning changing locations.
Jen: Yes, they are just less...So, like 3 times per year i, 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 so 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 ageement agreement with Erin's suggestion.
10:51:04 Sara: Sometimes checkincheck-in/out notes goes 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 and that would have no dependencies that would be totally item dependent and totally relevant for anything else to check.

10:52:21 Just

. Just going back to what I think

Aaron

Erin was saying earlier,

that

you know these things are just really

.10:52:25 Item

items and why shouldn't we be able to change them

okay

.

10

10:52:

32 Just mine, too.

38 Magda: I will follow up

So basically we have 2

. We have two options.

10:52:38

One. Add to the list of properties that are supported in the in-app approach or spend time on the

Cse

CSV approach for items.

10:52:55 And how

How does this group

fields, what

feel would be more beneficial?

10:53:03

Additional fields in the in

enough

-app 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

CSV approach?
Jen: My vote is for CSV.
Sara: I can see the benefit of the

Csv.10:53:41 Really

CSV really, truly, Yes, and

and

obviously there are a lot of things there that have to

become

be done 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

, for example, then users who do not necessarily have the permissions to do the

Cse version.10:54:11 Can

CSV version can take care of

an

in-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,

And making everything more permission-heavy is a barrier.
10:54:39

Yeah. but then so

Magda: So, Sarah, are you saying that you want to have a 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

. 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.

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

But if everything has to go towards the CSV because that's what

then?10:55:42 Yes

gets it done, then yes, of course, that's what...
Magda: I have to admit that I am surprised that I get so many

comes

thumbs up for

Csv

CSV because I was expecting I

will

would get a push back

from from

from

from

this group.

10:56:01

So thank you very much

. Put to speak back and for

for this feedback. In the long run, obviously, we would like to do the

enough

in-app approach to make it easier for the users.

10:56:13

But we are facing

. Give

the question of giving you something or

give you something.10:56:18 And Csv is the approach. that we can do this faster, but we put

giving you nothing and the CSV approach can be done faster but it puts a lot of responsibility on

on

the users.

10:56:28

However, as I said before, and I think

John

Jenn repeated it

.10:56:33 The

, the changes that

i'm

are being made with

csv

CSV can be

This is that re updated

reversed by submitting the file again.

10:56:43

But I will follow up with the

Mmc.10:56:48 1

MM SIG one more time, and to make sure I was

talk

talking to them about the

shan

deletion of items

, and we'll bring it to Csv. Mentioning

and will mention that this group strongly supports

Csv Approach Thank you.10:57:06 Very much. We have

the CSV approach.

Propagating suppress from discovery flag from instance to holdings and items records

Should this work to be done first on the inventory and then Bulk Edit or is this behavior Bulk Edit specific?

10:57:06 Magda: We have 3 min left, and I would like to use

those 3 min for the this.10:57:14 Follow up from

the 3 mins to follow up on 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

should automatically suppress the holdings and items. This is

Karen

currently not implemented on the inventory.

10:57:51

And my

question

basic question to this group is,

Do

do you think this is just

bulk edit,

Bulk Edit specific functionality?

10:58:05 Or this is the

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

This is jennifer x

Jennifer: I think

i

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 level. it's

it's

kind of the top

level.10:58:31 You know

-level whether or not you have an underlying

, you know, Mark Srs.10:58:36

MARC SRS. I mean in that case you're suppressing everything from discovery.

10:58:41

So it makes sense to

you know

suppress everything.
Magda: 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

to MM SIG as well. And if this is implemented

on the inventory, then we can

for Inventory then we reuse it very

easily

easy for the

bulk edit

Bulk Edit as well.
10:59:04 Mark: 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

in some cases, records will be unsuppressed in the future

,

because some

were keeping in some or not.10:59:36 ,

we are keeping and we are not. 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

suppressing the instance records

in

if it

,

suppresses everything underneath it.
10:59:59

But then, when I unsuppress, what needs to get unsuppressed apps, the item and holdings level11:00:12 This can get complicated. And how

Magda: And how are you using

those

that suppression?

11:00:18

Is this for or is this for OAI-PMH or something else?
Mark: 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

To facilitate that right now we are simply suppressing everything in the collection

.11:00:41 And

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

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

.
Magda: Yes

,

and I think there is also a question of

11:01:33

what will happen if you

to the

suppress

suppress

an instance

,

and you then 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

.
Mark: 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

:30 Magda:; I'm sorry I have to run to another meeting.

we will believe we

We will continue this

conversation.11:02:30 The

suppression conversation during

that, and then sick meeting.

the MM SIG meeting If I get on their schedule this week or next week

, we

. We still have the permissions

.11:02:40 For the expert

for the export manager. We will talk about this

, and and

next time

, and the Jennifer.11:02:48

. And Jennifer I saw your comment about the

bug edits and looked at the

Bulk Edit of item statuses

and

in 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

Bulk Edit. I will need to take a closer look at the implication of it and notification if needed

.11:03:10 We

we will add this in a Nolana as

a supported,

an 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

ll see you in 2 weeks 30 min later than normal. 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

10:44:58 These status and call up or type and the status in that case is on the instance, because the instance also has a status.

10:45:08 Oh, oh, yeah, you're right, yeah but sure yeah, yeah, item, status is definitely needed, and and we already implemented it.

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:44:19

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

Propagating suppress from discovery flag from instance to holdings and items records

Should this work to be done first on the inventory and then bulk edit or is this behavior bulk edit specific?

Permissions to Export Manager for accessing files with user records (UIBULKED-70)

. Bye.

Permissions to Export Manager for accessing files with user records (UIBULKED-70)

NEXT TIME

CHAT FILE

00:23:59 Thomas Trutt: my guess is it would be, since they are seprate apps.
00:30:46 Jennifer Eustis (she/her): They are gathering use cases for delete for instances
00:31:15 Jennifer Eustis (she/her): Complete list of use cases for Deletion of instances
00:31:34 Jennifer Eustis (she/her): We may want to open the discussion to holdings as well.
00:31:56 Jenn Colt: what you have in red here is true
00:33:00 Jackie Magagnosc: Right
00:33:16 Jackie Magagnosc: Sorry, typed in wrong window
00:34:30 Jenn Colt: if you do check dependencies
00:36:32 Jenn Colt: it wasn't hard except that the first version expected the API to check dependencies and it didn’t
00:36:39 Jenn Colt: so we had to reinstate a few loaned items
00:38:05 Jenn Colt: in general people don't want to have to ask us to do their work for them though so not a script is better for sure
00:39:03 Jackie Magagnosc: So much work needs to go through batch now and batch's plate is so very full, we feel guilty asking for something like deleting item records
00:39:04 Erin Nettifee: sure, i agree
00:39:14 Erin Nettifee: i just don't want people to think there are NO options
00:42:47 Sara Colglazier (MHC/5C): Sorry to ask this, but the in-app approach for item records modifies: item record locations (temp & perm) and statuses--Statuses here are like Missing? right--what about Loan Type (temp/perm)?
00:43:15 Jenn Colt: people shouldn't feel guilty! but i know it is an annoyance and just not how people want to work which is totally understandable. folks should be empowered to do their jobs.
00:45:58 Jenn Colt: temporary loan types are needed
00:46:13 Sara Colglazier (MHC/5C): right for reserves
00:46:19 Jenn Colt: yes
00:51:07 Sara Colglazier (MHC/5C): Item check in and check out note--would also be nice to be able to edit in bulk in-app
00:52:25 Sara Colglazier (MHC/5C): +1 to Erin
00:55:50 jeanette kalchik: +1 CSV
00:57:37 Bob Scheier (Holy Cross): I think for consistence we should get it in CSV first
00:57:48 Leeda Adkins: +1 Bob
00:59:03 Scott Perry (he/him): +1
00:59:07 Scott Perry (he/him): CSV
00:59:26 Jenn Colt: csv also you gives you a document to show people and have them approve
00:59:38 Jennifer Eustis (she/her): +1 Jenn
00:59:43 Scott Perry (he/him): I need to leave for my next meeting
01:00:12 Jackie Magagnosc: I don't love CSV, but the accountability and ability to reverse a change it provides verge on compelling
01:04:56 Sara & Tim Dannay : Bye gotta run

Versions Compared

Old Version 16

New Version Current

Key

Note Taker: