Have a pending order and go to: /cgi-bin/koha/acqui/parcel.pl?invoiceid=X Most of the columns you are able to sort but they summary column you cannot, it has the 'sorting_disabled' class. Librarians with large orders need to be able to sort by Summary.
*** This bug has been marked as a duplicate of bug 29464 ***
I forgot where this was at, sorry :-D
This is a bug that is costing my staff time every day. If we receive an order of 30 books and have to go into Acquisitions and click "received" on each title - it is much easy to find the titles when they are in alphabetical order. Otherwise it is a hunt and seek when the titles are listed in random order. So it might take anywhere from a few extra minutes for a small order to an extra 10 minutes for a larger order. Thank you, Catherine Ingram
(In reply to Tomás Cohen Arazi from comment #3) > I forgot where this was at, sorry :-D 1) Create a basket 2) Create orders 3) Close basket 4) Receive shipment 5) Enter invoice information 6) You should see your pending orders 7) Verify the 'Summary' column is no longer sortable.
Created attachment 130122 [details] [review] Bug 29570: Regression tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 130123 [details] [review] Bug 29570: Fix sorting orders by biblioitems columns The API representation of Koha::Biblio objects includes the biblioitems.* columns too. This proved problematic as queries had to get translated so they work (i.e. if a query passes q={"biblio.ean":"123%"} then the query needs to be tweaked so biblio.ean is translated into biblio.biblioitem.ean. This is solved, locally, in the controller. But sorting needs the same kind of tweak, and it was missing. This patch solves that by doing a similar conversion. To test: 1. Apply the regression tests patch 2. Run: $ kshell k$ prove t/db_dependent/api/v1/acquisitions_orders.t => FAIL: Tests fail, searching on a 'biblioitems' column generates a 500 error. 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! We can sort on those fields 5. Sign off :-D Note: you will notice the tests only cover sorting by ISBN. I consider it enough as sorting is a DB problem, and we only want to know if the generated ORDER BY is valid for the underlying query, and MySQL would complain if it wasn't the case. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 130124 [details] [review] Bug 29570: Enable sorting orders by summary This patch enables (on receiving) sorting orders by the summary column. It needs the previous patches to work. Title is given more precedence as expressed by users on the bug report. Which, by the way, makes sense. To test: 1. Create a basket 2. Create orders 3. Close basket 4. Receive shipment 5. Enter invoice information => SUCCESS: You should see your pending orders => FAIL: Verify the 'Summary' column is not sortable 7. Apply this patches 8. Restart Plack 9. Reload the page => SUCCESS: Can sort by the summary column 10. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 130125 [details] [review] Bug 29570: Regression tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 130126 [details] [review] Bug 29570: Fix sorting orders by biblioitems columns The API representation of Koha::Biblio objects includes the biblioitems.* columns too. This proved problematic as queries had to get translated so they work (i.e. if a query passes q={"biblio.ean":"123%"} then the query needs to be tweaked so biblio.ean is translated into biblio.biblioitem.ean. This is solved, locally, in the controller. But sorting needs the same kind of tweak, and it was missing. This patch solves that by doing a similar conversion. To test: 1. Apply the regression tests patch 2. Run: $ kshell k$ prove t/db_dependent/api/v1/acquisitions_orders.t => FAIL: Tests fail, searching on a 'biblioitems' column generates a 500 error. 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! We can sort on those fields 5. Sign off :-D Note: you will notice the tests only cover sorting by ISBN. I consider it enough as sorting is a DB problem, and we only want to know if the generated ORDER BY is valid for the underlying query, and MySQL would complain if it wasn't the case. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 130127 [details] [review] Bug 29570: Enable sorting orders by summary This patch enables (on receiving) sorting orders by the summary column. It needs the previous patches to work. Title is given more precedence as expressed by users on the bug report. Which, by the way, makes sense. To test: 1. Create a basket 2. Create orders 3. Close basket 4. Receive shipment 5. Enter invoice information => SUCCESS: You should see your pending orders => FAIL: Verify the 'Summary' column is not sortable 7. Apply this patches 8. Restart Plack 9. Reload the page => SUCCESS: Can sort by the summary column 10. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Tomas, shouldn't we deal with all biblioitem's attributes?
Comment on attachment 130126 [details] [review] Bug 29570: Fix sorting orders by biblioitems columns Review of attachment 130126 [details] [review]: ----------------------------------------------------------------- ::: Koha/REST/V1/Acquisitions/Orders.pm @@ +76,5 @@ > } > > + if ( exists $reserved_params->{_order_by} ) { > + # _order_by passed, fix if required > + for ( my $i = 0; $i < scalar @{$reserved_params->{_order_by}}; $i++ ) { You could write it in perl instead of javascript ;)
(In reply to Jonathan Druart from comment #12) > Tomas, shouldn't we deal with all biblioitem's attributes? It is your fault :P https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=115963
(In reply to Tomás Cohen Arazi from comment #14) > (In reply to Jonathan Druart from comment #12) > > Tomas, shouldn't we deal with all biblioitem's attributes? > > It is your fault :P > > https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=115963 Yes, do it like that :)
(In reply to Jonathan Druart from comment #13) > Comment on attachment 130126 [details] [review] [review] > Bug 29570: Fix sorting orders by biblioitems columns > > Review of attachment 130126 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: Koha/REST/V1/Acquisitions/Orders.pm > @@ +76,5 @@ > > } > > > > + if ( exists $reserved_params->{_order_by} ) { > > + # _order_by passed, fix if required > > + for ( my $i = 0; $i < scalar @{$reserved_params->{_order_by}}; $i++ ) { > > You could write it in perl instead of javascript ;) This is more C-ish
(In reply to Tomás Cohen Arazi from comment #14) > (In reply to Jonathan Druart from comment #12) > > Tomas, shouldn't we deal with all biblioitem's attributes? > > It is your fault :P > > https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=115963 Sorry, misunderstood what you were referring to. Fair enough then!
Created attachment 130308 [details] [review] Bug 29570: Regression tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 130309 [details] [review] Bug 29570: Fix sorting orders by biblioitems columns The API representation of Koha::Biblio objects includes the biblioitems.* columns too. This proved problematic as queries had to get translated so they work (i.e. if a query passes q={"biblio.ean":"123%"} then the query needs to be tweaked so biblio.ean is translated into biblio.biblioitem.ean. This is solved, locally, in the controller. But sorting needs the same kind of tweak, and it was missing. This patch solves that by doing a similar conversion. To test: 1. Apply the regression tests patch 2. Run: $ kshell k$ prove t/db_dependent/api/v1/acquisitions_orders.t => FAIL: Tests fail, searching on a 'biblioitems' column generates a 500 error. 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! We can sort on those fields 5. Sign off :-D Note: you will notice the tests only cover sorting by ISBN. I consider it enough as sorting is a DB problem, and we only want to know if the generated ORDER BY is valid for the underlying query, and MySQL would complain if it wasn't the case. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 130310 [details] [review] Bug 29570: Enable sorting orders by summary This patch enables (on receiving) sorting orders by the summary column. It needs the previous patches to work. Title is given more precedence as expressed by users on the bug report. Which, by the way, makes sense. To test: 1. Create a basket 2. Create orders 3. Close basket 4. Receive shipment 5. Enter invoice information => SUCCESS: You should see your pending orders => FAIL: Verify the 'Summary' column is not sortable 7. Apply this patches 8. Restart Plack 9. Reload the page => SUCCESS: Can sort by the summary column 10. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 130311 [details] [review] Bug 29570: Simplify for loop Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 130336 [details] [review] Bug 29570: Simplify for loop Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
Pushed to 21.11.x for 21.11.03
Pushed to 21.05.x for 21.05.11
Missing dependencies for 20.11.x, it shouldn't be affected, no backport.