Bug 31500 - Add ability to specify MaxReservesPickupDelay at the patron category level
Summary: Add ability to specify MaxReservesPickupDelay at the patron category level
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Kyle M Hall (khall)
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-31 16:44 UTC by Kyle M Hall (khall)
Modified: 2024-07-04 20:37 UTC (History)
4 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 31500: Update Scheme file [DO NOT PUSH] (1.49 KB, patch)
2022-08-31 17:41 UTC, Kyle M Hall (khall)
Details | Diff | Splinter Review
Bug 31500 - Add ability to specify MaxReservesPickupDelay at the patron category level (9.56 KB, patch)
2022-08-31 17:41 UTC, Kyle M Hall (khall)
Details | Diff | Splinter Review
syspref name is highlighted (8.16 KB, image/png)
2022-09-02 21:07 UTC, Andrew Fuerste-Henry
Details
Bug 31500: Update Scheme file [DO NOT PUSH] (1.55 KB, patch)
2022-09-02 21:11 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 31500 - Add ability to specify MaxReservesPickupDelay at the patron category level (9.62 KB, patch)
2022-09-02 21:11 UTC, ByWater Sandboxes
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall (khall) 2022-08-31 16:44:29 UTC
Some libraries would like to be able to override MaxReservesPickupDelay on a per category basis. A good use case for this is that some libraries have a special patron category for patrons that are from "out of town" on vacation. In this case, the library may want to specify a shorter pickup period before the item expires than they would for a patron that lives in the area.
Comment 1 Kyle M Hall (khall) 2022-08-31 17:41:43 UTC
Created attachment 140013 [details] [review]
Bug 31500: Update Scheme file [DO NOT PUSH]
Comment 2 Kyle M Hall (khall) 2022-08-31 17:41:53 UTC
Created attachment 140014 [details] [review]
Bug 31500 - Add ability to specify MaxReservesPickupDelay at the patron category level

Some libraries would like to be able to override MaxReservesPickupDelay on a per category basis. A good use case for this is that some libraries have a special patron category for patrons that are from "out of town" on vacation. In this case, the library may want to specify a shorter pickup period before the item expires than they would for a patron that lives in the area.

Test Plan:
1) Apply this patch, restart all the things!
2) Set MaxReservesPickupDelay to 5 days
3) Choose a patron category, go to the categories editor,
   near the bottom of the form is the new "Max holds pickup delay"
   field. Set this field to 10 days
4) Place a hold for an item using a patron of that category
5) Trap the hold so it is waiting
6) Note the expiration date is 10 days from now
7) Repeat steps 4-6 for a patron of a different category
8) Note the expiration date is 5 days out
Comment 3 Andrew Fuerste-Henry 2022-09-02 21:07:51 UTC
Created attachment 140189 [details]
syspref name is highlighted

Should the syspref name in the patron category edit screen be red and highlighted like this? It looks out of place, but I couldn't find other examples of sysprefs named in patron category or itemtype setup screens.

I'll also test functionality, but wanted to call out this display issue.
Comment 4 ByWater Sandboxes 2022-09-02 21:11:48 UTC
Created attachment 140190 [details] [review]
Bug 31500: Update Scheme file [DO NOT PUSH]

Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Comment 5 ByWater Sandboxes 2022-09-02 21:11:52 UTC
Created attachment 140191 [details] [review]
Bug 31500 - Add ability to specify MaxReservesPickupDelay at the patron category level

Some libraries would like to be able to override MaxReservesPickupDelay on a per category basis. A good use case for this is that some libraries have a special patron category for patrons that are from "out of town" on vacation. In this case, the library may want to specify a shorter pickup period before the item expires than they would for a patron that lives in the area.

Test Plan:
1) Apply this patch, restart all the things!
2) Set MaxReservesPickupDelay to 5 days
3) Choose a patron category, go to the categories editor,
   near the bottom of the form is the new "Max holds pickup delay"
   field. Set this field to 10 days
4) Place a hold for an item using a patron of that category
5) Trap the hold so it is waiting
6) Note the expiration date is 10 days from now
7) Repeat steps 4-6 for a patron of a different category
8) Note the expiration date is 5 days out

Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Comment 6 Andrew Fuerste-Henry 2022-09-02 21:14:57 UTC
Signed off because it works as described. See my note about the highlighting on the syspref name on /cgi-bin/koha/admin/categories.pl.

Also, I don't love the wording change on the Holds Awaiting Pickup page. Where it used to say "Holds waiting over X days" (where X is the value of MaxReservesPickupDelay). Now it says "Holds waiting over passed pickup date." I like the change to not give a number, since there is no longer an assumption of one accurate value. But that phrase is messy. 

Maybe just "Holds waiting past pickup date"?
Comment 7 Katrin Fischer 2022-10-03 15:03:11 UTC
(In reply to Andrew Fuerste-Henry from comment #6)
> Signed off because it works as described. See my note about the highlighting
> on the syspref name on /cgi-bin/koha/admin/categories.pl.
> 
> Also, I don't love the wording change on the Holds Awaiting Pickup page.
> Where it used to say "Holds waiting over X days" (where X is the value of
> MaxReservesPickupDelay). Now it says "Holds waiting over passed pickup
> date." I like the change to not give a number, since there is no longer an
> assumption of one accurate value. But that phrase is messy. 
> 
> Maybe just "Holds waiting past pickup date"?

I'll provide a follow-up with that change.
Comment 8 Katrin Fischer 2022-10-03 15:21:57 UTC
Ok, I will hold off providing the follow-up for now, because I think we should discuss the concept first:

To me, this feels not right on patron category level, I feel like it should be in in the circulation rules instead.

So I did some research:

1) There are patches to move ExpireReservesMaxPickUpDelayCharge to circulation rules, which would fit well together with the pickup delay:
* bug 25711 - ExpireReservesMaxPickUpDelayCharge (NSO)

2) There have been several bugs filed in present and past about moving the pickup delay to the circulation rules:

* bug 19309 - ReservesMaxPickUpDelay (marked duplicate)

Which argues:

Some libraries would love to have the option to specify the ReservesMaxPickUpDelay by itemtype, rather than specify the ReservesMaxPickUpDelay for all items via the system preference. There are times when specific item types like popular or new items, DVD's or even Museum passes may not want to sit on a shelf for 7 days waiting for the patron to pick it up. Versus a non popular item that can wait for 7 days for the patron to pick the item up. 

A use case I'd add is academic libraries with closed stacks where you might want to give a longer pickup-period before you return the items to the shelf.

And actually we have a competing bug with patches!

* bug 8367 - How long is a hold waiting for pickup at a more granular level (FQA)

I'd love if we could push the solution on bug 8367 instead of the patron category based solution.

We could say: we can do that later... BUT: there is no migration path. If we start with category level, we won't be able to populate values in the circulation rules later because of the * (all) rules. So I think this would be an argument for going circulation rules right away.
Comment 9 Andrew Fuerste-Henry 2022-10-03 15:35:42 UTC
Chiming in that I'm at one of those libraries that would really love to set pickup delay per itype rather than per patron category. I signed off on this because it seemed abstractly useful, but would rather not move forward here if it will make it harder to get itype distinctions working later.
Comment 10 Agnes Rivers-Moore 2022-10-03 15:48:41 UTC
Agreed, for my libraries, bug 8367 pickup delay by item type is the priority. Also I would prefer to keep this as a separate table in circ rules, not included in the large matrix which is already unwieldy, complicated and easy to make mistakes on.
How about adding pickup delay to Default reserves policy by item type - is that possible? Likewise for "Default checkout, hold policy by patron category" for those who do want to set pickup by patron type. Those would have to be mutually exclusive - each library would need to choose only one or the other, to avoid conflicting rules.
Comment 11 Kyle M Hall (khall) 2023-11-03 14:06:37 UTC
I do believe this feature is in the standard circ rules now so this is no longer needed!