Bug 32129 - Use patron categorycode of most relevant recall when checking if item can be a waiting recall
Summary: Use patron categorycode of most relevant recall when checking if item can be ...
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Aleisha Amohia
QA Contact: Testopia
URL:
Keywords:
Depends on: 19532
Blocks: 33726
  Show dependency treegraph
 
Reported: 2022-11-08 04:05 UTC by Aleisha Amohia
Modified: 2023-08-14 02:17 UTC (History)
7 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
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.
Version(s) released in:
23.05.00,22.11.06,22.05.14


Attachments
Bug 32129: Use patron category when checking if item can fill recall (3.45 KB, patch)
2022-11-08 20:16 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 32129: Use patron category when checking if item can fill recall (3.49 KB, patch)
2023-01-30 07:48 UTC, David Nind
Details | Diff | Splinter Review
Bug 32129: Use patron category when checking if item can fill recall (3.55 KB, patch)
2023-03-01 05:03 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review
Bug 32129: (QA follow-up) Avoid duplicate calculation (1.54 KB, patch)
2023-05-12 20:12 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Aleisha Amohia 2022-11-08 04:05:32 UTC
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.
Comment 1 Aleisha Amohia 2022-11-08 20:16:40 UTC
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
Comment 2 Hammat wele 2022-11-21 22:00:34 UTC
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
Comment 3 David Nind 2023-01-30 07:48:24 UTC
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>
Comment 4 David Nind 2023-01-30 07:50:08 UTC
(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-)
Comment 5 Victor Grousset/tuxayo 2023-03-01 05:03:47 UTC
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>
Comment 6 Victor Grousset/tuxayo 2023-03-01 05:04:42 UTC
Works, QA script happy, code looks good, passing QA :)
Comment 7 Tomás Cohen Arazi 2023-05-12 20:12:38 UTC
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.
Comment 8 Tomás Cohen Arazi 2023-05-12 20:54:25 UTC
Pushed to master for 23.05.

Nice work everyone, thanks!
Comment 9 Matt Blenkinsop 2023-05-15 13:06:09 UTC
Nice work everyone!

Pushed to stable for 22.11.x
Comment 10 Lucas Gass 2023-06-15 19:36:38 UTC
Backported to 22.05.x for upcoming 22.05.14
Comment 11 Danyon Sewell 2023-07-20 04:27:08 UTC
Not backporting for 21.11.x
Comment 12 Victor Grousset/tuxayo 2023-08-14 02:17:40 UTC
(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!