Expected behaviod when printing serials - add reserve?
Hi devs, I found an obvious bug in serials/routing-preview.pl. If the script is called with ok=1 (hum... yes...), the script will add or modify a hold placed on the bibliographic records existing in the routing list. So from /serials/serials-collection.pl?subscriptionid=1, click on "Print list" you get a pop-up with a print and close button. When the pop-up is generated, we already have the ok=1 and the go through: 66: my ($count2,@bibitems) = GetBiblioItemByBiblioNumber($biblio); Then later: 96 AddReserve($branch,$routing->{borrowernumber},$biblio,\@bibitems,$routing->{ranking}, undef, undef, $notes,$title); The problem is that GetBiblioItemByBiblioNumber will always return only 1 value (for obvious reasons) and @bibitems will always be empty => reserve is placed at bib level The thing is that this bug exists for ages (at least 2006, maybe always). What is the expected behaviour? No need to tell you that I was going to kick GetBiblioItemByBiblioNumber when I found that bug. Cheers, Jonathan
Hi Jonathan, I think placing a hold in the first place should depend on the RoutingListAddReserves system preference that has been broken for quite a while. I think someone told me that it was possible in the past to have a hold without an item? Not sure if that is true. But I would suggest this behaviour: - Use the system preference to determine, if a hold should be set - Only set item level holds. In order to pick the right item, this would then depend on "creating items on receive" with your subscription|.| |There are some bugs files related to this:| *Bug 2894* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2894> - Routing list holds are broken And the following one, that appeared to fix the problem in my testing, but is currently sitting in Failed QA: *Bug 7957* <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7957> - Routing lists: manage several routing list for each subscription, and export them as CSV Hope this helps, Katrin On 13.03.2017 17:25, Jonathan Druart wrote:
Hi devs,
I found an obvious bug in serials/routing-preview.pl <http://routing-preview.pl>. If the script is called with ok=1 (hum... yes...), the script will add or modify a hold placed on the bibliographic records existing in the routing list. So from /serials/serials-collection.pl?subscriptionid=1 <http://serials-collection.pl?subscriptionid=1>, click on "Print list" you get a pop-up with a print and close button. When the pop-up is generated, we already have the ok=1 and the go through: 66: my ($count2,@bibitems) = GetBiblioItemByBiblioNumber($biblio); Then later: 96 AddReserve($branch,$routing->{borrowernumber},$biblio,\@bibitems,$routing->{ranking}, undef, undef, $notes,$title);
The problem is that GetBiblioItemByBiblioNumber will always return only 1 value (for obvious reasons) and @bibitems will always be empty => reserve is placed at bib level
The thing is that this bug exists for ages (at least 2006, maybe always). What is the expected behaviour?
No need to tell you that I was going to kick GetBiblioItemByBiblioNumber when I found that bug.
Cheers, Jonathan
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hello Jonathan, I would say we should add holds only when the new issue is and syspref RoutingListAddReserves is on. Print list is bad action/time for that. The hold should be item level - as biblio level hold on serial is not really useful... Regards Josef po 13. 3. 2017 v 17:26 odesílatel Jonathan Druart < jonathan.druart@bugs.koha-community.org> napsal:
Hi devs,
I found an obvious bug in serials/routing-preview.pl. If the script is called with ok=1 (hum... yes...), the script will add or modify a hold placed on the bibliographic records existing in the routing list. So from /serials/serials-collection.pl?subscriptionid=1, click on "Print list" you get a pop-up with a print and close button. When the pop-up is generated, we already have the ok=1 and the go through: 66: my ($count2,@bibitems) = GetBiblioItemByBiblioNumber($biblio); Then later: 96 AddReserve($branch,$routing->{borrowernumber},$biblio,\@bibitems,$routing->{ranking}, undef, undef, $notes,$title);
The problem is that GetBiblioItemByBiblioNumber will always return only 1 value (for obvious reasons) and @bibitems will always be empty => reserve is placed at bib level
The thing is that this bug exists for ages (at least 2006, maybe always). What is the expected behaviour?
No need to tell you that I was going to kick GetBiblioItemByBiblioNumber when I found that bug.
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (3)
-
Jonathan Druart -
Josef Moravec -
Katrin