Bug 2894 - Routing list holds are broken
Summary: Routing list holds are broken
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: Serials (show other bugs)
Version: master
Hardware: All All
: P3 normal (vote)
Assignee: Jonathan Druart
QA Contact:
URL:
Keywords:
Depends on: 31335
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-05 09:00 UTC by Chris Cormack
Modified: 2023-08-06 08:24 UTC (History)
9 users (show)

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


Attachments
subscription holds (44.50 KB, image/png)
2012-02-19 13:36 UTC, Katrin Fischer
Details
Bug 2894: Fix Routing list holds (3.57 KB, patch)
2022-08-10 10:38 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:57:40 UTC


---- Reported by emily.funk@liblime.com 2009-01-05 09:00:14 ----

When creating a routing list for a serial, the hold that is placed for the patron is a BIB level hold, not an ITEM level hold. This means that all branches will see the hold when they pull their hold report.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:57 UTC  ---

This bug was previously known as _bug_ 2894 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2894

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was emily.funk@liblime.com.
CC member emily.funk@liblime.com does not have an account here

Comment 1 Paul Poulain 2011-08-02 13:40:14 UTC
I never use(d) routing lists. Could anyone confirm this problem ? Otherwise, i'll close the bug
Comment 2 Katrin Fischer 2012-02-19 13:36:46 UTC
Created attachment 7758 [details]
subscription holds

Ok, I have retested this on current master and something is seriously going wrong here. Updating version and severity as this feature seems to be totally broken right now.

Test 1:
- Create a new subscription, choose to NOT add items for the subscription
- Create a routing list
- Receive an issue
- Check for holds on the record
> Holds are created although you have no items for this record

I think there should be a check somewhere preventing that.
Perhaps making it not possible to create routing lists when no items are created?
I am not sure how this was supposed to work.

Test 2:
- Create a new subscription, choose to create items for the subscription on receive
- Create a routing list
- Receive an issue
- Check for holds on the record
> Holds are created, but those are indeed not item level. It seems to be some new kind of hold actually - 'only this type'? (see screenshot)

From the template:
      [% ELSE %]
        [% IF ( reserveloo.constrainttypeo ) %]
          only this type :<b>[% reserveloo.volumeddesc %] [% reserveloo.itemtype %]</b>
        [% END %]
      [% END %]
    [% END %]
Comment 3 Chris Cormack 2013-02-04 04:00:22 UTC
(In reply to comment #2)
> Created attachment 7758 [details]
> subscription holds
> 
> Ok, I have retested this on current master and something is seriously going
> wrong here. Updating version and severity as this feature seems to be
> totally broken right now.
> 
> Test 1:
> - Create a new subscription, choose to NOT add items for the subscription
> - Create a routing list
> - Receive an issue
> - Check for holds on the record
> > Holds are created although you have no items for this record
> 
> I think there should be a check somewhere preventing that.
> Perhaps making it not possible to create routing lists when no items are
> created?
> I am not sure how this was supposed to work.
> 
> Test 2:
> - Create a new subscription, choose to create items for the subscription on
> receive
> - Create a routing list
> - Receive an issue
> - Check for holds on the record
> > Holds are created, but those are indeed not item level. It seems to be some new kind of hold actually - 'only this type'? (see screenshot)

Some kind of old hold that people have since broken.

Ill have a look
> 
> From the template:
>       [% ELSE %]
>         [% IF ( reserveloo.constrainttypeo ) %]
>           only this type :<b>[% reserveloo.volumeddesc %] [%
> reserveloo.itemtype %]</b>
>         [% END %]
>       [% END %]
>     [% END %]
Comment 4 Katrin Fischer 2015-01-13 13:39:11 UTC
There is another side effect of this:

If you have RoutingListAddReserves to "place" in a 3.18 and you receive a new issue for the subscription, Koha tries to add a hold to the people on the routing list. 

This hold will break the new Ajax holds display so that no holds at all will display for this patron.

Solution: Turn off the pref and delete the holds with the wrong constraint type.
Comment 5 Katrin Fischer 2015-01-18 17:27:56 UTC
I thinks as this pref is causing problems when turned on, we should make sure it's turned off by default for new installations. Maybe also add a warning?

Fixing the problem would of course be preferred... but I think as this has been broken for a longer time, it's probably not easy.
Comment 6 Jonathan Druart 2015-07-14 13:53:08 UTC
Maybe bug 7957 fixes this bug?
Comment 7 Katrin Fischer 2015-07-14 14:04:56 UTC
Hm, maybe! At least the case when an item is created!
Comment 8 Patrick Robitaille 2018-07-23 18:45:09 UTC
Hi, 

are someone is working on this bug? It could be nice to use the systeme preference RoutingListAddReserves so when the users that you add to the circulation list will have automatically a created bookings in the order of adding to the list.

Thanks, Patrick.
Comment 9 Katrin Fischer 2019-05-04 18:40:19 UTC
Sadly, still valid after almost 9+ years :(
Comment 10 Andrew Fuerste-Henry 2021-02-11 21:50:51 UTC
I can confirm that on master currently holds for routing lists are still bib-level. They should be item-level.
Comment 11 Katrin Fischer 2021-04-12 09:32:21 UTC
When the feature is turned on it not only doesn't work now, but it also makes receiving issues explode - trying to place a hold insuccessfully in the background.
Comment 12 Jonathan Druart 2022-08-10 10:38:14 UTC
Created attachment 138971 [details] [review]
Bug 2894: Fix Routing list holds

This is a try to fix a very old bug. Not familiar with the workflow so
cannot confirm it will fix everything.
The idea is to fix the behaviour of RoutingListAddReserves, and create
item-level holds (so only if items have been created).
Comment 13 Jonathan Druart 2022-08-10 10:38:38 UTC
Patch for discussion.
Comment 14 Jonathan Druart 2023-05-04 13:05:33 UTC
Now that there are patches here and on the other linked bugs, can I get feedback on them please?
Comment 15 Jonathan Druart 2023-06-19 05:52:59 UTC
Changing status to Needs Signoff in hope to get feedback.
Comment 16 Michaela Sieber 2023-08-06 08:24:52 UTC
I think the idea to fix the behaviour of RoutingListAddReserves, and create
item-level holds (so only if items have been created) is correct.

When trying to apply patch I got the error message:
"Cannot apply cleanly patches from bug 31335. Everything will be left dirty."

Perhaps someone / developer could first have a look on bug 31335. As far as I understand this is about code cleaning.

And there should be a new test plan. 

Perhaps like this:

- Set systempref RoutingListAddReserves to "Place received serials on hold if they are on a routing list."
- Create a new subscription, e.g. for title "Chapman" (ISSN 0308-2695) 
- choose to create items for the subscription on receive
- Create a routing list with at least two recipients
- Receive an issue and fill item form (item type)
- Click on 'Print List' in column Routing
- Check for holds on the biblio record
> Holds are created, but those are indeed not item level. (see Holds column Details = Next available)

- Apply Patch
- Receive next issue with item
- Click on 'Print List' in column Routing
- Check for holds
- Holds should be on the item level for new received serial items