Created attachment 58015 [details] [review] Bug 17736: Add the Koha::Biblio->holds_placed_before_today method
Created attachment 58016 [details] [review] Bug 17736: Replace GetReservesFromBiblionumber with Koha::Biblio->holds The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the biblionumber, an optional itemnumber and a "all_dates" flag. If set, the subroutine returned all the holds placed on a given bibliographic record, even the ones placed in the future. Almost all of the calls had this flag set, they will be replaced with a call to Koha::Biblio->holds. But 5 did not have it: - C4::Biblio::DelBiblio -tools/batch_delete_records.pl => These 2 were wrong, we want to retrieve the holds to cancel them before deleting the record. We need to get all the holds, even the ones placed in the future /!\ CHANGE IN THE BEHAVIOR - acqui/parcel.pl => 1 call per item were made to this subroutine. They have been replaced with only 1 call to the new method Koha::Biblios->holds_placed_before_today Then we filter on the itemnumbers. I think this is wrong: we need the number of holds to know if the record can be deleted, so even if future holds exist, the deletion should not be possible. - serials/routing-preview.pl - C4::ILSDI::Services::GetRecords - C4::SIP::ILS::Item->new => Seems ok, we just one to display holds placed before today Test plan: I would suggest to test this patch with patches from bug 17737 and bug 17738, to place different kind of holds (biblio and item level, future and past). Then do a whole workflow to detect bug, view a record, delete record, order, place a hold on an item which has been ordered, etc. The hold's informations should always be the same without or without these patches.
Created attachment 58017 [details] [review] Bug 17736: Remove C4::Reserves::GetReservesFromBiblionumber At this point, there should not be any occurrences of GetReservesFromBiblionumber left in the codebase
Created attachment 58056 [details] Holds Trying to delete record with hold (title, or item level) through batch delete records tool: Bibliographic record 1 was not deleted. An error occurred. (The error was: Can't use string ("Koha::Biblio") as a HASH ref while "strict refs" in use at /home/vagrant/kohaclone/Koha/Object.pm line 219. , see the Koha log file for more information). Also, when returned reserved document has to be transfered, after the checking in on target library, everything looks ok. But the hold is not set to waiting status, see attached screenshot. It was title level hold.
Created attachment 58057 [details] Hold Detail Maybe the transit was not finished correctly?
Created attachment 58106 [details] [review] Bug 17736: Add the Koha::Biblio->holds_placed_before_today method
Created attachment 58107 [details] [review] Bug 17736: Replace GetReservesFromBiblionumber with Koha::Biblio->holds The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the biblionumber, an optional itemnumber and a "all_dates" flag. If set, the subroutine returned all the holds placed on a given bibliographic record, even the ones placed in the future. Almost all of the calls had this flag set, they will be replaced with a call to Koha::Biblio->holds. But 5 did not have it: - C4::Biblio::DelBiblio -tools/batch_delete_records.pl => These 2 were wrong, we want to retrieve the holds to cancel them before deleting the record. We need to get all the holds, even the ones placed in the future /!\ CHANGE IN THE BEHAVIOR - acqui/parcel.pl => 1 call per item were made to this subroutine. They have been replaced with only 1 call to the new method Koha::Biblios->holds_placed_before_today Then we filter on the itemnumbers. I think this is wrong: we need the number of holds to know if the record can be deleted, so even if future holds exist, the deletion should not be possible. - serials/routing-preview.pl - C4::ILSDI::Services::GetRecords - C4::SIP::ILS::Item->new => Seems ok, we just one to display holds placed before today Test plan: I would suggest to test this patch with patches from bug 17737 and bug 17738, to place different kind of holds (biblio and item level, future and past). Then do a whole workflow to detect bug, view a record, delete record, order, place a hold on an item which has been ordered, etc. The hold's informations should always be the same without or without these patches.
Created attachment 58108 [details] [review] Bug 17736: Remove C4::Reserves::GetReservesFromBiblionumber At this point, there should not be any occurrences of GetReservesFromBiblionumber left in the codebase
(In reply to Josef Moravec from comment #4) > Also, when returned reserved document has to be transfered, after the > checking in on target library, everything looks ok. But the hold is not set > to waiting status, see attached screenshot. It was title level hold. Could you give me more information on this please, I don't think I recreate it.
Testing this now
I would rather rename the sub. It is not about when the hold was 'placed' but if the hold pertains to the future or not. So my suggestion would be: Koha::Biblio->current_holds.
Created attachment 58628 [details] [review] Bug 17736: [Follow-up] Rename to current_holds It is not about when the hold was 'placed' but if the hold pertains to the future or not. Test plan: [1] Git grep on holds_placed_before_today. [2] Run t/db_dependent/Koha/Biblios.t [3] Run t/db_dependent/Reserves.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(In reply to Marcel de Rooy from comment #11) > I would rather rename the sub. It is not about when the hold was 'placed' > but if the hold pertains to the future or not. > So my suggestion would be: Koha::Biblio->current_holds. And also note that before today is not correct: should include today too. Added a proposal patch. Still testing.
Resolving a few errors like this too: Use of inherited AUTOLOAD for non-method Koha::Biblio::GetMarcBiblio() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Use of inherited AUTOLOAD for non-method Koha::Biblio::GetRecordValue() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. This happens because perl is looking first in Koha::Object (with AUTOLOAD) before it checks C4/Biblio. Rearranging the module order did not help either (moving C4/Biblio).
Created attachment 58629 [details] [review] Bug 17736: [Follow-up] Resolve inherited AUTOLOAD for non-method errors Like: Use of inherited AUTOLOAD for non-method Koha::Biblio::GetMarcBiblio() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Use of inherited AUTOLOAD for non-method Koha::Biblio::GetRecordValue() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Resolved by not importing them but fully qualifying them. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58630 [details] [review] Bug 17736: [QA Follow-up] Solve warning from qa tools on Holds.t FAIL t/db_dependent/Holds.t "my" variable $hold masks earlier declaration in same scope Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Ha: my $biblio = Koha::Biblios->find( $order->{ordernumber} );
Created attachment 58631 [details] [review] Bug 17736: [QA Follow-up] Wrong biblionumber in acqui/parcel Trivial fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug party! Do not assume that find gives you a Koha Object. Just see the following examples :)
Created attachment 58632 [details] [review] Bug 17736: [QA Follow-up] Crashes in basket.pl and parcel.pl Crash in basket.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/basket.pl line 466. Comes from a biblionumber == NULL in aqorders where I cancelled the order and deleted the biblio. Crash in parcel.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/parcel.pl line 246. Similar fix. Trivial fixes indeed. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58633 [details] [review] Bug 17736: [QA Follow-up] We do not need GetItemHolds in acqui The solution of Jonathan can be applied in two other cases, effectively making GetItemHolds obsolete. Test plan: [1] Git grep on GetItemHolds [2] Add an order, place a hold, delete order. [3] Add an order, receive, place hold, delete order.
Created attachment 58634 [details] [review] Bug 17736: [QA Follow-up] Script basket.pl is not Plack compliant Several warnings like: Variable "$confirm_pref" is not available at /usr/share/koha/masterclone/acqui/basket.pl line 507. Primarily caused by sub edi_close_and_order. Easy fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58635 [details] [review] Bug 17736: Add the Koha::Biblio->holds_placed_before_today method Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58636 [details] [review] Bug 17736: Replace GetReservesFromBiblionumber with Koha::Biblio->holds The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the biblionumber, an optional itemnumber and a "all_dates" flag. If set, the subroutine returned all the holds placed on a given bibliographic record, even the ones placed in the future. Almost all of the calls had this flag set, they will be replaced with a call to Koha::Biblio->holds. But 5 did not have it: - C4::Biblio::DelBiblio -tools/batch_delete_records.pl => These 2 were wrong, we want to retrieve the holds to cancel them before deleting the record. We need to get all the holds, even the ones placed in the future /!\ CHANGE IN THE BEHAVIOR - acqui/parcel.pl => 1 call per item were made to this subroutine. They have been replaced with only 1 call to the new method Koha::Biblios->holds_placed_before_today Then we filter on the itemnumbers. I think this is wrong: we need the number of holds to know if the record can be deleted, so even if future holds exist, the deletion should not be possible. - serials/routing-preview.pl - C4::ILSDI::Services::GetRecords - C4::SIP::ILS::Item->new => Seems ok, we just one to display holds placed before today Test plan: I would suggest to test this patch with patches from bug 17737 and bug 17738, to place different kind of holds (biblio and item level, future and past). Then do a whole workflow to detect bug, view a record, delete record, order, place a hold on an item which has been ordered, etc. The hold's informations should always be the same without or without these patches. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58637 [details] [review] Bug 17736: Remove C4::Reserves::GetReservesFromBiblionumber At this point, there should not be any occurrences of GetReservesFromBiblionumber left in the codebase Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58638 [details] [review] Bug 17736: [Follow-up] Rename to current_holds It is not about when the hold was 'placed' but if the hold pertains to the future or not. Test plan: [1] Git grep on holds_placed_before_today. [2] Run t/db_dependent/Koha/Biblios.t [3] Run t/db_dependent/Reserves.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58639 [details] [review] Bug 17736: [Follow-up] Resolve inherited AUTOLOAD for non-method errors Like: Use of inherited AUTOLOAD for non-method Koha::Biblio::GetMarcBiblio() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Use of inherited AUTOLOAD for non-method Koha::Biblio::GetRecordValue() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Resolved by not importing them but fully qualifying them. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58640 [details] [review] Bug 17736: [QA Follow-up] Solve warning from qa tools on Holds.t FAIL t/db_dependent/Holds.t "my" variable $hold masks earlier declaration in same scope Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58641 [details] [review] Bug 17736: [QA Follow-up] Wrong biblionumber in acqui/parcel Trivial fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58642 [details] [review] Bug 17736: [QA Follow-up] Crashes in basket.pl and parcel.pl Crash in basket.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/basket.pl line 466. Comes from a biblionumber == NULL in aqorders where I cancelled the order and deleted the biblio. Crash in parcel.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/parcel.pl line 246. Similar fix. Trivial fixes indeed. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58643 [details] [review] Bug 17736: [QA Follow-up] We do not need GetItemHolds in acqui The solution of Jonathan can be applied in two other cases, effectively making GetItemHolds obsolete. Test plan: [1] Git grep on GetItemHolds [2] Add an order, place a hold, delete order. [3] Add an order, receive, place hold, delete order. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 58644 [details] [review] Bug 17736: [QA Follow-up] Script basket.pl is not Plack compliant Several warnings like: Variable "$confirm_pref" is not available at /usr/share/koha/masterclone/acqui/basket.pl line 507. Primarily caused by sub edi_close_and_order. Easy fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This got out of hand somewhere in the process ;) But it works now (imo). The logic in basket.tt about showing hold numbers is still not working as it should. But should be further dealt with on another report. In parcel I used holds now instead of current_holds.
Created attachment 58645 [details] [review] Bug 17736: [QA Follow-up] Script basket.pl is not Plack compliant Several warnings like: Variable "$confirm_pref" is not available at /usr/share/koha/masterclone/acqui/basket.pl line 507. Primarily caused by sub edi_close_and_order. Easy fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Removed a debug warn.
Created attachment 59846 [details] [review] Bug 17736: Add the Koha::Biblio->holds_placed_before_today method Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59847 [details] [review] Bug 17736: Replace GetReservesFromBiblionumber with Koha::Biblio->holds The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the biblionumber, an optional itemnumber and a "all_dates" flag. If set, the subroutine returned all the holds placed on a given bibliographic record, even the ones placed in the future. Almost all of the calls had this flag set, they will be replaced with a call to Koha::Biblio->holds. But 5 did not have it: - C4::Biblio::DelBiblio -tools/batch_delete_records.pl => These 2 were wrong, we want to retrieve the holds to cancel them before deleting the record. We need to get all the holds, even the ones placed in the future /!\ CHANGE IN THE BEHAVIOR - acqui/parcel.pl => 1 call per item were made to this subroutine. They have been replaced with only 1 call to the new method Koha::Biblios->holds_placed_before_today Then we filter on the itemnumbers. I think this is wrong: we need the number of holds to know if the record can be deleted, so even if future holds exist, the deletion should not be possible. - serials/routing-preview.pl - C4::ILSDI::Services::GetRecords - C4::SIP::ILS::Item->new => Seems ok, we just one to display holds placed before today Test plan: I would suggest to test this patch with patches from bug 17737 and bug 17738, to place different kind of holds (biblio and item level, future and past). Then do a whole workflow to detect bug, view a record, delete record, order, place a hold on an item which has been ordered, etc. The hold's informations should always be the same without or without these patches. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59848 [details] [review] Bug 17736: Remove C4::Reserves::GetReservesFromBiblionumber At this point, there should not be any occurrences of GetReservesFromBiblionumber left in the codebase Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59849 [details] [review] Bug 17736: [Follow-up] Rename to current_holds It is not about when the hold was 'placed' but if the hold pertains to the future or not. Test plan: [1] Git grep on holds_placed_before_today. [2] Run t/db_dependent/Koha/Biblios.t [3] Run t/db_dependent/Reserves.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59850 [details] [review] Bug 17736: [Follow-up] Resolve inherited AUTOLOAD for non-method errors Like: Use of inherited AUTOLOAD for non-method Koha::Biblio::GetMarcBiblio() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Use of inherited AUTOLOAD for non-method Koha::Biblio::GetRecordValue() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Resolved by not importing them but fully qualifying them. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59851 [details] [review] Bug 17736: [QA Follow-up] Solve warning from qa tools on Holds.t FAIL t/db_dependent/Holds.t "my" variable $hold masks earlier declaration in same scope Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59852 [details] [review] Bug 17736: [QA Follow-up] Wrong biblionumber in acqui/parcel Trivial fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59853 [details] [review] Bug 17736: [QA Follow-up] Crashes in basket.pl and parcel.pl Crash in basket.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/basket.pl line 466. Comes from a biblionumber == NULL in aqorders where I cancelled the order and deleted the biblio. Crash in parcel.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/parcel.pl line 246. Similar fix. Trivial fixes indeed. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59854 [details] [review] Bug 17736: [QA Follow-up] We do not need GetItemHolds in acqui The solution of Jonathan can be applied in two other cases, effectively making GetItemHolds obsolete. Test plan: [1] Git grep on GetItemHolds [2] Add an order, place a hold, delete order. [3] Add an order, receive, place hold, delete order. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 59855 [details] [review] Bug 17736: [QA Follow-up] Script basket.pl is not Plack compliant Several warnings like: Variable "$confirm_pref" is not available at /usr/share/koha/masterclone/acqui/basket.pl line 507. Primarily caused by sub edi_close_and_order. Easy fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
trivial rebase on c4/biblio; giving 17737 a try
Created attachment 59859 [details] [review] Bug 17736: Fix typo ->new vs ->next while ->new is terrible, let's call that a typo...
Created attachment 59860 [details] [review] Bug 17736: Fix typo ->new vs ->next while ->new is terrible, let's call that a typo... Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> opac-detail works again !
Created attachment 61406 [details] [review] Bug 17736: Add the Koha::Biblio->holds_placed_before_today method Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61407 [details] [review] Bug 17736: Replace GetReservesFromBiblionumber with Koha::Biblio->holds The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the biblionumber, an optional itemnumber and a "all_dates" flag. If set, the subroutine returned all the holds placed on a given bibliographic record, even the ones placed in the future. Almost all of the calls had this flag set, they will be replaced with a call to Koha::Biblio->holds. But 5 did not have it: - C4::Biblio::DelBiblio -tools/batch_delete_records.pl => These 2 were wrong, we want to retrieve the holds to cancel them before deleting the record. We need to get all the holds, even the ones placed in the future /!\ CHANGE IN THE BEHAVIOR - acqui/parcel.pl => 1 call per item were made to this subroutine. They have been replaced with only 1 call to the new method Koha::Biblios->holds_placed_before_today Then we filter on the itemnumbers. I think this is wrong: we need the number of holds to know if the record can be deleted, so even if future holds exist, the deletion should not be possible. - serials/routing-preview.pl - C4::ILSDI::Services::GetRecords - C4::SIP::ILS::Item->new => Seems ok, we just one to display holds placed before today Test plan: I would suggest to test this patch with patches from bug 17737 and bug 17738, to place different kind of holds (biblio and item level, future and past). Then do a whole workflow to detect bug, view a record, delete record, order, place a hold on an item which has been ordered, etc. The hold's informations should always be the same without or without these patches. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61408 [details] [review] Bug 17736: Remove C4::Reserves::GetReservesFromBiblionumber At this point, there should not be any occurrences of GetReservesFromBiblionumber left in the codebase Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61409 [details] [review] Bug 17736: [Follow-up] Rename to current_holds It is not about when the hold was 'placed' but if the hold pertains to the future or not. Test plan: [1] Git grep on holds_placed_before_today. [2] Run t/db_dependent/Koha/Biblios.t [3] Run t/db_dependent/Reserves.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61410 [details] [review] Bug 17736: [Follow-up] Resolve inherited AUTOLOAD for non-method errors Like: Use of inherited AUTOLOAD for non-method Koha::Biblio::GetMarcBiblio() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Use of inherited AUTOLOAD for non-method Koha::Biblio::GetRecordValue() is deprecated at /usr/share/koha/masterclone/Koha/Biblio.pm line 60. Resolved by not importing them but fully qualifying them. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61411 [details] [review] Bug 17736: [QA Follow-up] Solve warning from qa tools on Holds.t FAIL t/db_dependent/Holds.t "my" variable $hold masks earlier declaration in same scope Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61412 [details] [review] Bug 17736: [QA Follow-up] Wrong biblionumber in acqui/parcel Trivial fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61413 [details] [review] Bug 17736: [QA Follow-up] Crashes in basket.pl and parcel.pl Crash in basket.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/basket.pl line 466. Comes from a biblionumber == NULL in aqorders where I cancelled the order and deleted the biblio. Crash in parcel.pl: Can't call method "holds" on an undefined value at /usr/share/koha/masterclone/acqui/parcel.pl line 246. Similar fix. Trivial fixes indeed. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61414 [details] [review] Bug 17736: [QA Follow-up] We do not need GetItemHolds in acqui The solution of Jonathan can be applied in two other cases, effectively making GetItemHolds obsolete. Test plan: [1] Git grep on GetItemHolds [2] Add an order, place a hold, delete order. [3] Add an order, receive, place hold, delete order. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61415 [details] [review] Bug 17736: [QA Follow-up] Script basket.pl is not Plack compliant Several warnings like: Variable "$confirm_pref" is not available at /usr/share/koha/masterclone/acqui/basket.pl line 507. Primarily caused by sub edi_close_and_order. Easy fix. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 61416 [details] [review] Bug 17736: Fix typo ->new vs ->next while ->new is terrible, let's call that a typo... Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> opac-detail works again ! Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Tested pretty thoroughly and is looking solid to me. Thanks for the efforys Jonathan and for the thorough testing Marcel. Passing QA!
Pushed to master for 17.05, thanks Jonathan, Marcel!
This won't get ported back to 16.11.x as it is an enhancement.