Expected behaviod when printing serials - add reserve?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Expected behaviod when printing serials - add reserve?

Jonathan Druart
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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Expected behaviod when printing serials - add reserve?

Katrin Fischer-2

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 - 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 - 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.
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
[hidden email]
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/


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Expected behaviod when printing serials - add reserve?

Josef Moravec
In reply to this post by Jonathan Druart
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 <[hidden email]> 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
[hidden email]
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/

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Loading...