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

[Josef Moravec]

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 at 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, 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/20170525/ff89cfe4/attachment.html>