[Magda lost her connection for a couple of minues and then returned at around 11:14]
Magda 11:14
I'm back.
Erin: We just jumped a topic, while we were waiting for you to come back.
Magda 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 're 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 try 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 has 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.
Unknown Speaker 11:37
yeah. I mean, we've changed long rules. And that's always an issue. Yeah.
Unknown Speaker 11:45 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?
Unknown Speaker 11:57
I agree. Erin 41:07
I'm not sure how you would. So I'm looking, I'm actually looking at the ramp at the loan record .Unknown Speaker 12:06
Because because I'm trying to see what what's actually stored on it. So thereThere's actually what I'm trying to see is there's actually not a location on the loan.Unknown Speaker 12:20
no location on the loan. What you see in the UU ID is stuff that's extrapolated from the item record. But there's actually not Yeah, well, okay. So thereThere's an effective location at checkout of the item loan loaned to the patron. Um, I mean, I'm sure there are libraries that would use that would do that. And so , you know, if it's, if it's something that can be done. Sure. I guess I just I thinkUnknown Speaker 12:48
it's not the highest priority, I would Unknown Speaker 12:51
not consider it the highest priority.
Unknown Speaker 12:54 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 . Going back to the loan type is you have a service point as a bad calendar, you need to fix something.
Unknown Speaker 13:05 Erin 42:15
Yeah, yeah. Therethere's also a checkout service point idea ID that's on the record. Yeah. Yeah, I agree with Thomas.
Unknown Speaker 13:15
Yeah. But Thomas 42:22
I also agree with what Aaron Erin was saying before with location is patrons . 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.
Unknown Speaker 13:32
Yeah, right. Erin 42:42
So Christina is saying in the chat that she thinks Michigan State when you would use location if it was available,Unknown Speaker 13:38
okay. So, yeah. Unknown Speaker 13:43
And that can definitely, 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 sensitively sensibly for them. I also know that the Center for Research Libraries is using their its location tree to like extrapolate to their its membership, and so I could see them really wanting that. So yeah. Yeah, and Jen is pointing out that reserves sometimes are, are location-based, and you could want to do it there. Yeah, that that makes a lot of sense. I don't know how often you would change a due date for short-term loans, but there 's are definitely scenarios whereUnknown Speaker 14:41
this .
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 this? Request? Hold the sorry, not request the alone due dates.
Unknown Speaker 15:02
Well, I will let the Scorpios know that we talked about this today. You know,
Unknown Speaker 15:08
for loan due dates? I will schedule in a time with the essay to discuss and review it. I'm not sure what they do the who is the convener of the
Unknown Speaker 15:20
conveners. Jana? I think that somebody I think she's on vacation right now and somebody else is covering for her. It's Cornelia Arrhenius. Okay. Okay. It's covering for her right now. So you could try both Cornelia and Jana. And and the group meets Mondays and Thursdays,
Unknown Speaker 15:44
okay. We'll probably not be able to meet this Thursday, but maybe Monday. Thank you. Thank you very much.
Unknown Speaker 15:55
And they would also for request, hold shelf expiration dates, they will also be the group to talk to about that. So we can, okay, I need to drop off of that. 1055. Just FYI.
Unknown Speaker 16:06
So you're saying that for the request called updates, I shouldn't
Unknown Speaker 16:12
shelf expiration date, you have the whole thing in the sentence. And then you have just request hold date in the column on the left. So just to be clear, we're talking about the whole shelf expiration date? Yes,
Unknown Speaker 16:23
we are talking about hold shelf expiration date, we are not talking about request expiration date, unless you think it would make sense to combine them.
Unknown Speaker 16:35
So right now, the request expiration date is not set by anything. There's nothing that puts that on by default. You can put a date in there if you want, but it's optional. So I think there are scenarios where you would want to be able to do that. And so, but I don't know that it needs to be part of this feature. Unless it's simple to do. If that makes sense. I think the need the use cases for the hold shelf expiration date are much more common. And they're going to be very similar, have similar use cases to the loan, due date change, it's going to be the building is inaccessible for some period of time it's going to be it might be things like, you know, our our van is broken down. And we kept making deliveries for two days, that has happened to do more than I would like to care to admit. And so you want to just give a little bit more time for hold for requests to be manageable.
Unknown Speaker 17:39
Okay. Oh, should the should the request status, which request status just shouldn't be impacted?
Unknown Speaker 17:48
So there's only one it's going to be? Let me pull up the request app, it's going to be awaiting open a waiting for pickup.
Unknown Speaker 18:01
And this is the only one.
Unknown Speaker 18:04
Because what am Thomas please correct me if I'm wrong, open awaiting delivery doesn't get a whole shelf expiration date, because it's not going on a hold shelf?
Unknown Speaker 18:12
We've asked correct, but we don't use delivery. So
Unknown Speaker 18:16
yeah. 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 whole shelf eventually.
Unknown Speaker 18:36
Or those that aren't being delivered, right?
Unknown Speaker 18:41
Well, but you can have a hold that's delivered a page that's delivered every call that's delivered. Okay. So, but go ahead, sir. Yeah. But you're also gonna have all three of those end up as open awaiting pickup. So.
Unknown Speaker 18:58
Yeah. And this similar question about the how the request should be identified.
Unknown Speaker 19:06
Definitely pick up service point. And definitely a request ID there is no request, HR. You can all right, you could also do it by user ID. Or I can't imagine why you would do patron group, but user ID for sure.
Unknown Speaker 19:32
The only thing I could think of for Patreon group would something with like, when we first enter COVID where all the undergrads got kicked off campus. That's the only thing I could think of that scenario. But
Unknown Speaker 19:45
sure, yeah.
Unknown Speaker 19:49
Yeah, yeah.
Unknown Speaker 19:51
In that case, I feel that we would just extend everything so right
Unknown Speaker 20:03
Okay, so I think I got a lot of information for those two and I will follow up with to circulation peer, and we are a singer. Hopefully next week and come I will come back to this group if I have more questions. And the next one is about the permission, removing or adding permission to the existing to the users. And I am nervous when it comes to permission, and I'm glad that we have Aaron here. But what would be the most common use case for removing or adding permission? Someone is leaving the university or joining the University? Student began university it's employment. Yeah. Okay.
Unknown Speaker 21:05
It's your you're joining 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 is student employees. And that's absolutely true. That's the that's the case, though of you're joining the library, you're leaving the library?
Unknown Speaker 21:30
I think that'd be our biggest use case would be just an employment, individual users, we probably just changed the UI.
Unknown Speaker 21:37
Okay, so you would identify that the permissions by user barcodes and user groups
Unknown Speaker 21:46
are not just barcodes, any identifier? Yes, user identity UID, external system, 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. Because it's also not. There's also I think, use cases that are like, right, because because you're really talking about employment groups, and they don't employment groups don't translate to patron group at most libraries. Okay.
Unknown Speaker 22:34
This is to identify the records. So wouldn't you want to identify a group called students as a group to take away their search? Permissions?
Unknown Speaker 22:47
Not unless I'm firing every single student worker? Well, I
Unknown Speaker 22:51
mean, not really like in our case, we're small. So we have, you know, a handful of students. And if we were going to use their user record for their permissions, you know, at the desk, and then every semester we change staff, but in that case, we probably just do them one at a time. Are many
Unknown Speaker 23:11
is also saying that most libraries don't, don't have that kind of all or nothing turnover. Right? Right. I might have 40 students leave and students remain. So
Unknown Speaker 23:23
you're right. Yep. Yeah.
Unknown Speaker 23:25
Is there anything in the permissions with that? Non library staff would need to use something like self checkout? Are I just, I'm just trying to think of any weird permissions that might have to be added to our large group of people because of an external service?
Unknown Speaker 23:49
No, because you should have an edge module in most cases, and the edge module, does it. Okay, um, 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 no permission set called student desk workers. And please show me every user that has this permission set, and please take it away from them, that we
Unknown Speaker 24:15
assign permission. Yes, this is.
Unknown Speaker 24:18
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.
Unknown Speaker 24:45
I know this be very niche, but what about a silencer service point? Now
Unknown Speaker 24:53
because you know well, I mean, But yeah, I guess you're talking about the assigned service point on the user record.
Unknown Speaker 25:08
I guess. Yeah. I was I was thinking about the request record. But yeah, yeah, you could see that. So, you know, I want to see all the, I want to take permissions away from all the people who were assigned to XYZ permitted Service Desk,
Unknown Speaker 25:24
or bumped them up to a different permission or changed your permissions, or change
Unknown Speaker 25:28
their permissions. Yeah, that's, that's probably more likely, you know, although in that case, you should be using permission sets and just changing permission set.
Unknown Speaker 25:38
True, true. I just trying to think of other clients, and that one, I would put as definitely a lower priority, because it would definitely be focused more on circulation. Sure, and there'll be other ways to get that data. But sure.
Unknown Speaker 25:53 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 up frontupfront, I do believe, however, the the identifiers way would be the faster way to retrieve the records, then than the dynamic query, but we will get to this once we start talking about the queries, we have seven minutes left.
Unknown Speaker 26:28
And I need to do after my next meeting.
Unknown Speaker 26:33
Thank you for your feedback. And please send me that to JIRAs. Thank you very much. And Magda 55:49
I would like to spend the last few minutes of the meeting talking about the query. I have only Jira, JIRA. I don't have any mock-ups yet. And it will be a while until we 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, it comes up. And this the query that is currently implemented for user records and in a very minimal way for item records . It's is cumbersome , and the performance is not as bad. And this This is definitely not the way to go. So we We need to build a tool that will visually guide the user in through the process of building the a query. And when I say visually guide, I mean , to provide the list of supported fields, provide the list of the wreck records that can be access, accessed given the starting point, and things like that. When we start when we will 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 records typerecord types. What would I mean by that? First, we will build the UI query, for example, for searching user records, or item records, then . Then once we have the circulation log, we will be able to Okay, when do I have the circulation log, let's say in loans. I have a 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?
Unknown Speaker 29:00 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 have the Ask ask the apps to build this query structure within themselves? So right now, there is there is 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, we suppose just my thought.
Unknown Speaker 0:23
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 modules in other apps, I actually was thinking of data export. So you will be able to buy or build the query in data export. Or you could use the plugin in, like you said, in inventory, but also users, because in user records, you have a very limited, very limited ways of building the building, like setting that just a few options.
Unknown Speaker 1:15
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 Korea.
Unknown Speaker 1:23
Yes, this is the long run plan, starting with the bulk edit, because in all conversation from the day one, when I started to talk about Bulk Edit, everybody talks about query. And like everybody starts with the query. So I think there was no way of going away with bulk edit with without giving you the option of building some way, some way of building the query. And the other part of this process is how the results will be rendered on the on the landing page on the bucket landing page. Right now, we are showing top 10. As we discussed this last time, which may work when you submit the list of identifiers, assuming that you get generated the list of identifiers on some other ways of querying. But if you build the query, if you build the query, you cannot see on the top 10 records, you will need to see the whole list. And we also talked about that last time that you feel that top 10 It's not enough, you would like to be able to page through the through the results. So I put this into this feature, I'm not sure if this will not be a separate feature where we will be working on pagination of the results. So the user can go through the pages similarly, how it is done in in inventory, first time, the next step, etc. And going back and forth. The 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 also something that you select the records and only dose records are updated. This is somehow similar to the way I don't know if any one of you did the bulk edit in JIRA. But this is also how JIRA does, you get the list of the records that you provided query for, 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 we need. 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
Transcribed by https://otter.ai