Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold.
Created attachment 46462 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold
I can't apply this patch on master. I get: fatal: sha1 information is lacking or useless (C4/HoldsQueue.pm). error: could not build fake ancestor
(In reply to Frédéric Demians from comment #2) > I can't apply this patch on master. I get: > > fatal: sha1 information is lacking or useless (C4/HoldsQueue.pm). > error: could not build fake ancestor Applying: Bug 15533 - Allow patrons and librarians to select itemtype when placing hold fatal: sha1 information is lacking or useless (C4/HoldsQueue.pm). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 15533 - Allow patrons and librarians to select itemtype when placing hold The copy of the patch that failed is found in: /var/koha/koha/.git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-15533---Allow-patrons-and-librarians-to-select-UnO2iN.patch
I'm having no trouble applying the patch. Did you apply it's dependency ( Bug 15532 ) first?
(In reply to Kyle M Hall from comment #4) > I'm having no trouble applying the patch. Did you apply it's dependency ( > Bug 15532 ) first? You're right, patch apply without trouble
Created attachment 48262 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold
Created attachment 49227 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold
Created attachment 49469 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Created attachment 50016 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se> Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Created attachment 50145 [details] [review] Bug 15533: Fix 'ambiguous' SQL query in CanItemBeReserved Adding reserves.itemtype made a query to fail in CanItemBeReserved. This patch prefixes the column names with the corresponding table names to prevent that. You can trigger the error by running prove t/db_dependent/Holds.t You should see something like this: Column 'itemtype' in where clause is ambiguous
Created attachment 50926 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se> Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Created attachment 50927 [details] [review] Bug 15533: Fix 'ambiguous' SQL query in CanItemBeReserved Adding reserves.itemtype made a query to fail in CanItemBeReserved. This patch prefixes the column names with the corresponding table names to prevent that. You can trigger the error by running prove t/db_dependent/Holds.t You should see something like this: Column 'itemtype' in where clause is ambiguous
Created attachment 50928 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se> Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Created attachment 50929 [details] [review] Bug 15533: Fix 'ambiguous' SQL query in CanItemBeReserved Adding reserves.itemtype made a query to fail in CanItemBeReserved. This patch prefixes the column names with the corresponding table names to prevent that. You can trigger the error by running prove t/db_dependent/Holds.t You should see something like this: Column 'itemtype' in where clause is ambiguous
Ok, starting with code review and found a few things: 1) Please make this feature optional! I think not all libraries will want to use it, while it's very useful for others. I'd suggest to add a preference here, so it can't be circumvented like CSS would allow to. 2) Some smallish translation issues, easy to fix: <i>Next available <b>[% ItemTypes.GetDescription( reserveloo.itemtype ) %]</b> item</i> Pending for next available <i>[% ItemTypes.GetDescription( RESERVE.itemtype ) %]</i> item Tests and QA script pass. I will continue testing a bit more!
Created attachment 50931 [details] [review] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se> Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Created attachment 50932 [details] [review] Bug 15533: Fix 'ambiguous' SQL query in CanItemBeReserved Adding reserves.itemtype made a query to fail in CanItemBeReserved. This patch prefixes the column names with the corresponding table names to prevent that. You can trigger the error by running prove t/db_dependent/Holds.t You should see something like this: Column 'itemtype' in where clause is ambiguous
Created attachment 50933 [details] [review] Bug 15533 [QA Followup] - Add a system preference
Created attachment 50934 [details] [review] Bug 15533 [QA Followup] - Move tags for translatability
Found a problem: When placing multiple holds at once from the result list, the itemtype list is not correct - It seems to show the itemtypes from the first record. This allows you to place 'unfillable' holds - as there are no items of this itemtype on the other records necessarily.
Another thing: The requested itemtype is perfectly visible in the patron account in the OPAC, but not on the holds summary page of the record nor in the patron account in staff (Checkouts and detail tabs)
On a positive note: holds are not triggered for the wrong itemtype, but are triggered for the correct one. Setting holds with the pref off still works as expected. Kyle, can you please take a look at the last 2 comments?
Created attachment 50937 [details] [review] Bug 15533 [QA Followup] - Itemtype limit missing from tables
Created attachment 50941 [details] [review] Bug 15533 [QA Followup] - All itemtypes for all items showing in OPAC multi-hold
Created attachment 50942 [details] [review] Bug 15533 [QA Followup] - All itemtypes for all items showing in OPAC multi-hold
Created attachment 50943 [details] [review] [PASSED QA] Bug 15533 - Allow patrons and librarians to select itemtype when placing hold Some libraries would like the ability to select the itemtype to request when placing holds. For example, if a record has 3 copies of BookA and 3 copies of BookA in large print, this feature would allow a person to place a hold on the record, but still be able to target only the Large Print edition so that the first Large Print copy that becomes available is targeted, rather than forcing the patron to select a particular copy to hold. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with items of two or more itemtypes 4) Place a record level hold on the record while choosing one particular itemtype 5) Check in an item from the record that is not of that itemtype 6) Notee it is not trapped for the hold 7) Check in an item from the record that does match the selected itemtype 8) Note the item is trapped for the hold Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se> Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 50944 [details] [review] [PASSED QA] Bug 15533: Fix 'ambiguous' SQL query in CanItemBeReserved Adding reserves.itemtype made a query to fail in CanItemBeReserved. This patch prefixes the column names with the corresponding table names to prevent that. You can trigger the error by running prove t/db_dependent/Holds.t You should see something like this: Column 'itemtype' in where clause is ambiguous Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 50945 [details] [review] [PASSED QA] Bug 15533 [QA Followup] - Add a system preference Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 50946 [details] [review] [PASSED QA] Bug 15533 [QA Followup] - Move tags for translatability Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 50947 [details] [review] [PASSED QA] Bug 15533 [QA Followup] - Itemtype limit missing from tables Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 50948 [details] [review] Bug 15533: QA follow-up - Formatting and improving translatability - Makes new message in the holds tables in the patron account translatable - Unbolds the note in the holds table for the record
Created attachment 50949 [details] [review] [PASSED QA] Bug 15533 [QA Followup] - All itemtypes for all items showing in OPAC multi-hold Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Pushed to Master - should be in the May 2016 - Release. Thanks Katrin!
*** Bug 17619 has been marked as a duplicate of this bug. ***
What version is this pushed to?
(In reply to Kyle M Hall from comment #33) > Pushed to Master - should be in the May 2016 - Release. Thanks Katrin! 16.05