https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 140014 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140014&action=edit 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewfh@dubcolib.org --- Comment #3 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- Created attachment 140189 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140189&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 ByWater Sandboxes <bws.sandboxes@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #140014|0 |1 is obsolete| | --- Comment #5 from ByWater Sandboxes <bws.sandboxes@gmail.com> --- Created attachment 140191 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140191&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=8367 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 Agnes Rivers-Moore <arm@hanover.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arm@hanover.ca --- Comment #10 from Agnes Rivers-Moore <arm@hanover.ca> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31500 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|In Discussion |RESOLVED --- Comment #11 from Kyle M Hall <kyle@bywatersolutions.com> --- I do believe this feature is in the standard circ rules now so this is no longer needed! -- You are receiving this mail because: You are watching all bug changes.