We check in (return) an item to trigger the recalls process and set it as waiting for the patron who requested the recall. Sometimes the recalls process isn't triggered, and there is no other way to alert the patron that their item is ready for them to pick up if they've recalled it. This is because of more specific circulation rules. When we check if an item can be set as waiting to fill a recall, we do not consider the category code.
Created attachment 143449 [details] [review] Bug 32129: Use patron category when checking if item can fill recall This patch uses the patron category of the patron who requested the most relevant recall to check for more specific circulation rules relating to recalls. This ensures that patrons who are allowed to place recalls are able to fill their recalls, especially when recalls are not generally available for all patron categories. To test: 1) Go to Administration -> System preferences and enable UseRecalls 2) Go to Administration -> Circulation and fines rules and set a general All/All rule and a Category A/Itemtype A rule. All values can be set however you like except for these recalls rules: All/All rule: Recalls allowed: 0 Recalls per record: 0 On shelf recalls allowed: if any unavailable Category A/Itemtype A rule: Recalls allowed: 5 Recalls per record: 5 On shelf recalls allowed: if any unavailable 3) Find an item of Itemtype A. Check it out to Patron A (any category). 4) Log into the OPAC as Patron B (of Category A). Find the item and place a recall on the item. 5) Back in the staff interface, check in the item. This should trigger the recalls process so you can allocate the item to Patron B's recall, however the pop-up box to confirm the recall does not show. This is the bug. 6) Apply the patch and restart services 7) Check in the item again. Confirm the pop-up box to confirm the recall shows and you are able to allocate the item to Patron B's recall. 8) Confirm tests pass t/db_dependent/Koha/Item.t Sponsored-by: Auckland University of Technology
I am unable to reproduce the original bug. Steps performed: 1) Go to Administration -> System preferences and enable UseRecalls 2) Go to Administration -> Circulation and fines rules and set a general All/All rule and a Category A/Itemtype A rule. All values can be set however you like except for these recalls rules: All/All rule: Recalls allowed: 0 Recalls per record: 0 On shelf recalls allowed: if any unavailable Category A/Itemtype A rule: Recalls allowed: 5 Recalls per record: 5 On shelf recalls allowed: if any unavailable 3) Find an item of Itemtype A. Check it out to Patron A (any category). 4) Log into the OPAC as Patron B (of Category A). Find the item and place a recall on the item. 5) Back in the staff interface, check in the item => there is already a pop-up box showed to confirm the recall
Created attachment 145795 [details] [review] Bug 32129: Use patron category when checking if item can fill recall This patch uses the patron category of the patron who requested the most relevant recall to check for more specific circulation rules relating to recalls. This ensures that patrons who are allowed to place recalls are able to fill their recalls, especially when recalls are not generally available for all patron categories. To test: 1) Go to Administration -> System preferences and enable UseRecalls 2) Go to Administration -> Circulation and fines rules and set a general All/All rule and a Category A/Itemtype A rule. All values can be set however you like except for these recalls rules: All/All rule: Recalls allowed: 0 Recalls per record: 0 On shelf recalls allowed: if any unavailable Category A/Itemtype A rule: Recalls allowed: 5 Recalls per record: 5 On shelf recalls allowed: if any unavailable 3) Find an item of Itemtype A. Check it out to Patron A (any category). 4) Log into the OPAC as Patron B (of Category A). Find the item and place a recall on the item. 5) Back in the staff interface, check in the item. This should trigger the recalls process so you can allocate the item to Patron B's recall, however the pop-up box to confirm the recall does not show. This is the bug. 6) Apply the patch and restart services 7) Check in the item again. Confirm the pop-up box to confirm the recall shows and you are able to allocate the item to Patron B's recall. 8) Confirm tests pass t/db_dependent/Koha/Item.t Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com>
(In reply to Hammat wele from comment #2) > I am unable to reproduce the original bug. I was able to reproduce the bug in master (tested using koha-testing-docker), and have signed off. 8-)
Created attachment 147529 [details] [review] Bug 32129: Use patron category when checking if item can fill recall This patch uses the patron category of the patron who requested the most relevant recall to check for more specific circulation rules relating to recalls. This ensures that patrons who are allowed to place recalls are able to fill their recalls, especially when recalls are not generally available for all patron categories. To test: 1) Go to Administration -> System preferences and enable UseRecalls 2) Go to Administration -> Circulation and fines rules and set a general All/All rule and a Category A/Itemtype A rule. All values can be set however you like except for these recalls rules: All/All rule: Recalls allowed: 0 Recalls per record: 0 On shelf recalls allowed: if any unavailable Category A/Itemtype A rule: Recalls allowed: 5 Recalls per record: 5 On shelf recalls allowed: if any unavailable 3) Find an item of Itemtype A. Check it out to Patron A (any category). 4) Log into the OPAC as Patron B (of Category A). Find the item and place a recall on the item. 5) Back in the staff interface, check in the item. This should trigger the recalls process so you can allocate the item to Patron B's recall, however the pop-up box to confirm the recall does not show. This is the bug. 6) Apply the patch and restart services 7) Check in the item again. Confirm the pop-up box to confirm the recall shows and you are able to allocate the item to Patron B's recall. 8) Confirm tests pass t/db_dependent/Koha/Item.t Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Works, QA script happy, code looks good, passing QA :)
Created attachment 151160 [details] [review] Bug 32129: (QA follow-up) Avoid duplicate calculation This patch stores the output from ->check_recall() (a Koha::Recall object or undef) and reuses afterwards, on a ternaty operator.
Pushed to master for 23.05. Nice work everyone, thanks!
Nice work everyone! Pushed to stable for 22.11.x
Backported to 22.05.x for upcoming 22.05.14
Not backporting for 21.11.x
(In reply to Tomás Cohen Arazi from comment #7) > Created attachment 151160 [details] [review] [review] > Bug 32129: (QA follow-up) Avoid duplicate calculation > > This patch stores the output from ->check_recall() (a Koha::Recall > object or undef) and reuses afterwards, on a ternaty operator. Thanks for catching this Tomás!