Loan dates updates (use cases and possible dependencies)Requests hold dates updates (use cases and dependencies)Permissions removal (and addition)Advanced query for single recordsMagda 11:15
I appreciate that. And I heard the end of the conversation. And this is the behavior you want in the bulk edit as well? So if the user enters invalid data, the data should be accepted because I see that you can set the expiration date value to be empty, but it sets the user as inactive. Is this expected behavior correct?
Erin 11:51
Wait, say that again.
Magda 11:56
So if the user enters something that is invalid and cannot be transformed into the date format, the data in the expiration date is left blank, but the user remains active. Is that the expected behavior
Erin 13:40
So I happen to know that because I'm following another ticket that there is some work going on about validating that field. I will send you the JIRA in Slack so you can take a look at it. So I think there is some work happening right now where they are trying to put it in. And so I would say that at that point, then you would get an error message back. And that would be reported because mod users would say, Hey, that's not a valid date.
Magda 14:13
The validation occurs on the UI, right? It does not occur on the back end.
Erin 14:19
There's no validation in either place. They are talking about doing it in both places.
Magda 14:27
[Magdo demonstrates the following current behavior in bulk edit for the group] In bulk edit right now, if you enter an invalid date and process a bulk edit to update a user record date, the result completes with no error but does not process any updates.
Erin 14:50
I really do think these two user JIRAs are relevant. And it's worth looking at them and then deciding the best path. So I will tag you on those so you can take a look.
Magda 16:58
Great. Thank you very much. And the next part is the conversation about loan.
Magda 17:07
Well, I didn't talk about the bugs. We skipped that section. So I'm not sure if you want to go back to that or not.
Magda 17:14
Okay. So, as I said, MODEXPW-150 is in in progress. And this will be a deployed probably tomorrow to the bugfest environment, and we will validate that. So this will for sure make the Morning Glory release.
Magda 17:14
The known issues we talked about this during our last meeting, how the expected behavior for the record counts when the item bulk edit is triggered by holdings - UIBULKED-122. It will be implemented in Nolana. But it will be marked as a non-issue for Morning Glory. The same with multi data export worker, MODEXPW-203 - "Fail to upload file" error with large amount of Users barcodes. This happens intermittently, with large amount of user barcode, approximately 10,000. We have addressed this issue it is already fixed, but it did not make our Morning Glory release.
Magda 18:35
And the performance test results. I don't think they have changed since our last conversation. Are they any questions? Comments? Okay, great. I would like to move to the features that I would like to address in our next release, after Nolana. And I admit, I am entering a territory that I'm not really familiar with. This is circulation. I want us to go into this territory because I would like us to start looking into cross app queries, building the queries across apps that we can address in the release following Orchid which is Poppy. If we have user data and item data, the record that is linking them are either loans or requests. And I would like to start with loan due dates and request hold dates updates because they seem to be pretty high on the list of use cases. But also, we already have some experience with the due dates. So hopefully we could address that quickly if there are no issues that we should consider. So, I don't know if you had the chance to take a look at the at the
| Jira Legacy |
|---|
| server | System JIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | UXPROD-3805 |
|---|
|
which is just very high-level information. So, what we will be updating will be the loan due date. The other dates are out of scope unless you indicate otherwise. And the query of the records will be covered in a separate story in the future. The questions are listed on the agenda. So, I would like to ask you for the most common use case for changing loan due dates. The use cases mentioned were having to do with the pandemic and closures due to inclement weather. What are the other use cases that the library that would need to update loan due dates?Erin 21:59
It is broader than the pandemic. It is needed anytime a building needs to close. And that can be for all sorts of reasons. Jeanette is mentioning in the chat that they close the building for two weeks and over winter break. And if there are due dates during that timeframe, they would want to change that. You can control some of that with circulation calendars. But being able to do a bulk change for due dates would be applicable in any of those scenarios.
Thomas 22:50
I know David in RA SIG has mentioned rolling things over for the next semester for people. But that is more of a renewal instead of a due date change.
Erin 23:04
Right, it's important to note that those are different functions. Changing due dates versus renewing an item. Because changing a due date, you're modifying an existing loan, but by renewing an item you are checking against rules, and things like that when you're changing a due date, you're not really checking against any rules.
Magda 23:25
So this actually confirms that this is kind of the simplest update for the loans. If we start venturing into...
Erin 23:41
It's not as simple as you would hope. There are definitely dependencies here.
Magda 23:51
So please go ahead.
Unknown Speaker 23:54
So the major dependency that I can think of is fees and fines. If you change the due date for something that is overdue or is aged to lost? And if an item is recalled, you can change the due date on that item already. But you may have dependencies or implications if the item had been recalled--what happens to the recall request. And then if there's a request queue behind it, does anything change there?
Unknown Speaker 25:16
So yeah, because the library's closed...
Erin 25:21
They're absolutely use cases for doing that. And the user record loan view does not stop you from doing that if an item has been recalled.
Magda 25:35
And what would be the expected behavior if the item is marked as aged to lost?
Erin 25:45
That's a good question. And I might have to go try it. Because if I change the due date, I might reopen a loan, but I don't know if the loan would then change that. That would then change the item status, right? Because you can change a loan due date. But if the item status is aged to lost, I don't think that changing the due date changes the item status.
Thomas 26:21
I don't think it does either. I think renewing changes the item status. If you can renew it through lost? I think you're correct. I think if you just change the due date, you just change the due date.
Magda 26:35
And no changes in the item status?
Erin 26:41
Yeah, I don't think it does. So you do have the potential there, then to screw some things up? I think the question is, what's the expected behavior? Do you expect the bulk edit app to do things? Or do you just document that the user will need to follow up with another bulk edit to update the item status?
Thomas 27:21
This is where it gets really tricky when you get outside of Circ. logic.
Erin 27:24
This might be something that needs to go to the RA SIG, Magda, because I don't know what they would expect. I also want to check with Books Travis, I have this memory that there's an API for changing the due date that the UI doesn't use for some reason. The UI just doesn't put to loan records. Go ahead Thomas.
Thomas 27:59
I was gonna say I'm in our test system right now. And I pulled up something that was aged to lost, and in the UI the change due date function is disabled. So my guess is that it was disabled. Because if you try to change the due date, it's gonna mess up a bunch of business logic, somewhere down the line.
Erin 28:24
Okay. And that's not a permissions issue, because you have full permissions.
Thomas 28:30
Yeah, I have full permissions.
Erin 28:33
So then maybe that answer Magda. If it's aged to lost then it would not change the due date. Another one you would treat the same way is declared lost, because declared lost also has an associated fine record.
Thomas 29:03
What about claimed return? Because that kind of throws in a weird limbo.
Erin 29:09
Can you claim an item return and change the due date? Do you have an example you could try that on? Okay, well, Thomas will try that. To answer your second question there, it should not include loan and return dates. Those are on the loan record and you should not change those. There is a feature to back data return. But I would not back data. I would want to look at that separately.
Magda 30:22
I agree because I think it will increase the complexity if we start looking into renewals, because we need to check the policies about the allowed number of renewals and all these things. So that's good.
And the third question, what should be specified as a loan action? I saw that currently when you update the loan records manually, the action is due date change. I was wondering if we need to include a new a new action that would be bulk due date change.
Erin 31:25
That's a good question. So where those actions often show up is not just in the loan record, but in the circulation log. I can't remember if the circulation log has a due date change as an action. Let me look and see.
Erin 31:52
It does. So if I bulk edited 100 loans and change their due date, I would want them to show up in that Circ. log And that's probably where that loan action is important. And so we could add a loan action that would then have a dependency on work in the search log to make sure that it showed up there. I'm not entirely sure everywhere that that is used. And I'm not sure how that might be used in reporting. Because I should be able to do a record and be able to look at or change the due date and be able to see the user who did it.
Magda 32:36
But this metadata will be recorded anyway.
Erin 32:43
That's another good question for the RA SIG to see if there are other cases where we've had something like this, and how we've treated it in terms of the Circ. log. The PO for the Circ. log is still Stephanie Buck.
Magda 33:02
Yes, I can reach out to her and the same development team that I'm working with was working on Circulation log.
Erin 33:13
Are there any others here, is there any reason we can think of to add another loan action? Yeah, absolutely.
Thomas 33:21
I mean, the other possibility is you could change the source, instead of having a username, you could have a username and bulk edit. So that kind of falls into the pattern. It uses the same filters and everything else.
Thomas 33:33
I think what is happening now is the bulk edit is triggered by the user. So the records modified by the bulk edit has the user.
Erin 33:52
Right. Versus just pulling from the metadata object? It wouldn't have anything extra in there. Yeah.
Thomas 33:59
So I did go in and set up a test case and try to claim returned. Once you hit claim returned, renewal and change due date is not an option. So it looks like the only time you can change a due date is if the circulation record is open.
Erin 34:16
The loan is open. And it's checked out.
Thomas 34:20
Correct?
Erin 34:22
Okay, so there's your answer, Magda.
Magda 34:23
So for all other statuses, you would deny and report it. Right?
Erin 34:36
Yeah, that would definitely be something you would want to be recorded back.
Magda 34:41
So question number five, the renewal count should be updated?
Erin 34:48
You would not update the renewal count because this is not a renewal.
Magda 34:53
And then how should the loan records be identified?
Erin 35:18
There's no HRID for a loan.
Magda 35:22
Okay, this simplifies things.
Erin 35:24
There's just a UUID on the loan record. I would not do it by location. Because I don't know what you would mean by location.
Magda 35:36
I think there was one use case that they said that they would like to make a change based o a location. I think this also falls into the case where some part of the library is being closed. So then you would identify this part of the library by location.
Erin 36:09
There could be scenarios where a particular library is closed, but the locations of the items that you want to change the due dates on could be all over. Because it could be like the service point for this particular remote campus is closing. And so we don't want the users to have to return things there. But they may have books from other multiple branches, right? So is this a thing where we can say please do it by more than one identifier? Like we've done in other cases? Or do we need to like really specify it down?
Magda 36:55
Can you repeat that?
Erin 37:02
Sure. I guess I'm saying like, how many? How many identifiers? Loan ID is obvious to me, especially if you have access to a reporting tool, because you can use a reporting tool to get a list of loan UUIDs, and then you can just feed that into a bulk edit tool. I think item IDs probably also make sense and item barcodes. Because I could see scenarios that you can extrapolate to a location. You can say show me all the barcodes in this particular location. I will say that I do think this needs to be able to report, I would say that it might be common if I have a list of barcodes to set it into Bulk Edit. And to say that at least some of those maybe aren't actually on loan. Right? Like let's say that this location has 1000 books, I want to extend all the loans and all I have is a list of barcodes. So I'm just going to send 1000 barcodes into here. So if this process changes the due date, and I give it a list of items, and it doesn't find a loan on the item, that should be reported back. But I do think item barcodes and item UUIDs make sense to me. User UUIDs also make sense. Because you could, for example, say this group of 50 users was on a trip to South America and they were stuck there for a month. And I just want to renew all their books or change the due date on all their books. So that would also be something that I would think people would want to be able to do.
Thomas 38:55
Even with users, I would say if possible, patron type.
Erin 39:07
Yeah, I couldn't see that. Or patron group Magda.
Erin 39:11
That could lead to a scenario with performance issues. Because if you're submitting a list of and trying to process all the patrons in the group faculty. It could be a lot. And there are definitely use cases to do that. But yeah, I don't Yeah.
Thomas 39:34
The other one, too, since we're dealing with Circ. records. Would you also want to filter by loan policy? If you have a bad loan policy you wanted to clean up.
Magda 39:55
But if you have a bad loan policy? Will you be using it to identify the records that need to have the due date updated?
Erin 40:03
It's stored on the loan? So what Thomas's imagining is, we loaned books for a month, and then we were like, oh crap, these all got the wrong due dates. And we went in and fixed the loan policy, but those existing loans don't get updated when you do that. So I would not make that a higher priority, but I do think that would probably be pretty simple to do in the context of the work they're doing because it has the UUID for the loan policies stored on the loan. So that's an interesting idea.
Magda 40:55
So the question I have is, I'm sorry, I'm going back to this. Are you sure we don't need location?
Erin 41:07
I'm not sure how you would. So I'm actually looking at the loan record because I'm trying to see what's actually stored on it. There's actually no location on the loan. What you see in the UU ID is stuff that's extrapolated from the item record. There's an effective location at checkout of the item loaned to the patron. I'm sure there are libraries that would do that. And so if it's something that can be done. Sure. I would not consider it the highest priority.
Thomas 42:03
I would say even what might be higher than that is service point. What service point was the item checked out from. Going back to the loan type is you have a service point as a bad calendar, you need to fix something.
Erin 42:15
Yeah, there's also a checkout service point ID that's on the record. Yeah. Yeah, I agree with Thomas.
Thomas 42:22
I also agree with what Erin was saying before with location. Patrons could have things checked out from different service points, and different locations all over the place. So trying to narrow down a specific group of things that need to have their due dates changed by that criteria.
Erin 42:42
So Christina is saying in the chat that she thinks Michigan State would use location if it was available. And I can imagine that being something that smaller libraries would probably use more than bigger libraries, even though Michigan State is obviously very large. I know that for libraries that are similar, a lot of times their locations are smaller. And so that may be something that extrapolates a lot more sensibly for them. I also know that the Center for Research Libraries is using its location tree to extrapolate to its membership, so I could see them really wanting that. Jen is pointing out that reserves sometimes are location-based, and you could want to do it there. Yeah, that makes a lot of sense. I don't know how often you would change a due date for short-term loans, but there are definitely scenarios.
Magda 42:50 This was a great discussion. Is there anything else that you think I should keep in mind while gathering the requirements for loan due dates? I will schedule a time to discuss this with the RA SIG (Convener is Jana Freytag).
Erin 45:30
RA would also be the folks to discuss hold shelf expiration dates with. Request expiration dates does not need to be part of this feature unless it is easy to do. Hold shelf expiration date is much more common and the use cases will be similar to loan due dates.
Magda 46:57
Which request status just should be impacted?
Erin 47:00
So there's only one it's going to be? Let me pull up the request app, it's going to be open waiting pickup.Thomas please correct me if I'm wrong, but open awaiting delivery doesn't get a whole shelf expiration date, because it's not going on a hold shelf?
Thomas 47:22
I believe that is correct, but we don't use delivery.
Unknown Speaker 47:27
So it's really just open, awaiting pickup. And then the request types that should be impacted would be all of them. Because all request types end up on a hold shelf eventually.
Magda 47:45
Or those that are being delivered, right?
Erin 47:50
But you can have a hold, page, or recall that's delivered. But you're also gonna have all three of those end up as open awaiting pick up.
Magda 48:09
And a similar question about how the request should be identified.
Erin 48:15
Definitely pick up service point. And definitely a request ID. Tthere is no request HRID. You can also do it by user ID. I can't imagine you would do patron group, but user ID for sure.
Thomas 48:41
The only thing I could think of for patron group would something like, when we first enter COVID where all the undergrads got kicked off campus. That's the only thing I could think of in that scenario. In that case, I feel that we would just extend everything.
49:15
Okay, so I think I got a lot of information for those two and I will follow up with to circulation PO and RA SIG hopefully next week, and come I will come back to this group if I have more questions. The next one is about permissions, removing or adding permissions to existing users. And I am nervous when it comes to permissions. I'm glad that we have Erin here. But what would be the most common use cases for removing or adding permissions? Someone is leaving the university or joining the University? Students becoming employed by the university.
Erin 50:19
It's library employment. You're leaving library employment. Amanda is also pointing out in the chat that you're changing job duties. So maybe you're a staff member, but you're moving to a different role. Jennifer is saying the most common are student employees. And that's absolutely true. That's the case when you are joining the library, you're leaving the library.
Thomas 50:39
I think that'd be our biggest use case change in employment, individual users we probably just change it in the UI.
Magda 50:47
Okay, so you would identify the permissions by user barcodes and user groups?
Erin 50:56
Not just barcodes. Any identifier: UUID, external system ID, barcode and username. I personally wouldn't do it by user group. Because when you're hiring a student, you're not usually changing their user group. But I don't know if other libraries would have that use case. We're really talking about employment groups, and they don't translate to patron groups at most libraries.
Erin 53:05
Christine is mentioning that being able to search by an assigned permission set would be useful. Okay, when assigned permission, I could definitely see that scenario. So I have a permission set called student desk workers. And please show me every user that has this permission set, and please take it away from them the assign permission.
Erin 53:35
But there's also I think there's a technical piece to this that's worth keeping in mind, it might be worth talking to, I think core platform about whether you edit the existing user permission record or whether you just delete the permission record, it's worth talking to core platform about the right way to do that. But that's a little a little rabbit holy, sorry.
Thomas 53:55
I know this be very niche, but what about assigned service point?
Erin 54:31
Yeah, I could see that. So, you know, I want to take permissions away from all the people who were assigned to XYZ permitted Service Desk.
Thomas 54:35
Or bumped them up to different permission or changed their permissions.
Magda 55:02
And eventually, we will have the query. And the query will definitely ease the burden of identifiers which we need to provide upfront, I do believe, however, the identifiers would be faster way to retrieve the records, than the dynamic query, but we will get to this once we start talking about the queries, we have seven minutes left.
Magda 55:49
I would like to spend the last few minutes of the meeting talking about the query. I have only JIRA. I don't have any mock-ups yet. And it will be a while until we get to the mock-ups. But there are two things that I would like to get your feedback on. The scope is basically something that comes up in every conversation when we talk about searching. And the query that is currently implemented for user records and in a very minimal way for item records is cumbersome and the performance is bad. This is definitely not the way to go. We need to build a tool that will visually guide the user through the process of building a query. And when I say visually guide, I mean to provide the list of supported fields, provide the list of the records that can be accessed given the starting point, and things like that. When we start working on the query tool, we will start with supporting just one record type. And down the road, we will be adding support for multiple record types. What would I mean by that? First, we will build the UI query, for example, for searching user records, or item records. Then once we have the circulation log, we will be able to have the circulation log, the loan I then have the loan record. So I would like to build the query based on user records and item records. Is this clear? Or am confusing you?
Thomas 58:10
It makes sense. But I'm kind of wondering, as you're describing this, as you're saying about creating a query interface that spans multiple apps, would it be more efficient to instead ask the apps to build this query structure within themselves? So right now, there are some query functions in inventory to make that more robust instead of building like a separate system, come up with a pattern that can then be applied to users or applied to inventory. I know it won't create a one-stop shopping, which would be nice. But I think it makes the system more robust, just my thought.
Magda 55:56
So this is an awesome question. And actually, when I'm thinking about this tool, I think of it as a plugin, as a plugin that can be reused in other apps. I actually was thinking of data export. So you will be able to build the query in data export or use the plugin in inventory, but also users, because, in user records, you have very limited ways of searching.
Thomas 59:51
Okay, that makes more sense. So this would be just kind of like a generic plugin that any app could pick up and then use for queries.
Magda 59:55
Yes, this is the long term plan. In all the conversations from day one when we started to talk about Bulk Edit, everybody talks about query. There is no way that bulk edit will not have the option of building a query. And the other part of this process is how the results will be rendered on the landing page in Bulk Edit. Right now, we are showing the top 10. This may work when you submit the list of identifiers, assuming that you generated the list of identifiers in some other ways of querying. But if you build the query, you cannot see only the top 10 records. You will need to see the whole list. And we also talked last time how you feel that the top 10 It's not enough. You would like to be able to page through the results. So I put this into this feature. I am not sure if this will not be a separate feature where we will be working on the pagination of the results. So the user can go through the pages similarly, to how it is done in inventory. The ideal option would be also narrowing the list of records by selecting them, again something that similarly exists in inventory when you select a checkbox, and then you export those selected records. Here you would be building a set of records via the query but also allowing you to select the records and only those records are updated. This is similar to how JIRA does it. You get the list of the records that a query provided, but you can still narrow down the list. And we are on top of the hour. And we will probably come back to this next time. If you have any questions, please let me know. comments as well. Sounds good. Thank you. Thank you. I'll talk to you in two weeks. Bye bye