[Koha-devel] Expected behaviod when printing serials - add reserve?

[Katrin]

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, at 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 at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20170314/4b94e490/attachment-0001.html>