Our Acquisitions workflow is currently hindered by a repetitive process of receiving individual items. The parcel.pl and orderreceive.pl scripts in Koha 3.5 do not provide us with a way to checkbox individual items for receipt, or alternatively, "Receive All." We have to click receive on each item, then save the individual item and return to the receive screen. On orders where we have a hundred items, you can imagine this process of receiving is very tiresome, when a "Receive All" function could be implemented. Because several Acquisitions team members may be receiving items in the same basket, a checkbox on each line and a "Receive checked" would allow each worker to receive their specific items - giving the option to check all and receive, or just receive the items on your specific physical cart. This would be a benefit when large orders are being processed. By combining orderreceive.pl and finishreceive.pl we expect to be able to automate the process for batch receiving of items on an order.
Created attachment 9881 [details] Our local Acquisitions Workflow What are alternative workflows? I understand we can also create items through cataloging or when receiving them, using the AcqCreateItems system preference.
This would be a great addition. Often I physically receive all the items in my basket and have to go through several steps in order to receive just one item. It takes up a lot of time.
I would love to have this capability to batch receive big orders like YBP or Worldwide.
This would be a great enhancement. Being able to receive multiple items using check-boxes would make it so much more efficient and would be a time saver. For example, if I receive a basket from Amazon, my invoice # is the same as my basket #, so I would love to see the items from the basket prepopulate in my invoice, have a "receive all" option or just have check boxes to select the ones I have and close the invoice. If more items come in on a different day, I could reopen the invoice and check off those items (it would be date stamped with the day of receipt).
+1
Created attachment 111437 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t
Created attachment 111438 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql
Created attachment 111439 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref
Created attachment 111440 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Argh... so sad now 26635 applied correctly ! Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 8179: Add tests Using index info to reconstruct a base tree... M t/db_dependent/Koha/Acquisition/Order.t Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Koha/Acquisition/Order.t CONFLICT (content): Merge conflict in t/db_dependent/Koha/Acquisition/Order.t Failed to merge in the changes. Patch failed at 0001 Bug 8179: Add tests
Created attachment 112554 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t
Created attachment 112555 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql
Created attachment 112556 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref
Created attachment 112558 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
(In reply to Séverine Queune from comment #10) > Argh... so sad now 26635 applied correctly ! > > Apply? [(y)es, (n)o, (i)nteractive] y > Applying: Bug 8179: Add tests > Using index info to reconstruct a base tree... > M t/db_dependent/Koha/Acquisition/Order.t > Falling back to patching base and 3-way merge... > Auto-merging t/db_dependent/Koha/Acquisition/Order.t > CONFLICT (content): Merge conflict in t/db_dependent/Koha/Acquisition/Order.t > Failed to merge in the changes. > Patch failed at 0001 Bug 8179: Add tests Hi, just rebased this bug. Could you please try again? Thanks!
Hi Augustin, I got an issue with the /cgi-bin/koha/acqui/parcel.pl? page which stays 'Processing' (see here with the console log : https://snipboard.io/V1WPGy.jpg). I had the same issue testing Bug 20212 last week, but the last version proposed by Tomas on Friday fixed that. Loading this page is correct when I switch to master, I also try creating a branch with 20212 only and it was correctly display too, so no idea from which other patch it can come from...
Created attachment 112588 [details] [review] Bug 8179: Set render functions in every column Because when AcqReceiveMultipleOrderLines is set to allow, we add an extra column at the beginning, general columnDefs of datatables config pointed to the wrong column. So, instead of using general columnDef, this patch sets the render function to each column.
Hi Agustin, No "Processing" problem anymore ! But I now get this Software error trying to receive an order, whenever I use the current "Receive" link or the new checkbox : Can't locate Data/Printer.pm in @INC (you may need to install the Data::Printer module) (@INC contains: /var/repositories/koha /home/koha/perl5/lib/perl5/x86_64-linux-gnu-thread-multi /home/koha/perl5/lib/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . /home/koha/koha-dev/var/lib/plugins) at /var/repositories/koha/acqui/orderreceive.pl line 141. BEGIN failed--compilation aborted at /var/repositories/koha/acqui/orderreceive.pl line 141. No error when I switch back to master. I stop the test at step 12, but for step 14, could we imagine to ass the usual options "Check all / Uncheck all" we have on other Koha pages ? I know it would be useful, especially if we use it combined with filters on basket for example or author if a collection must be receipted.
(In reply to Séverine Queune from comment #18) > Hi Agustin, > No "Processing" problem anymore ! > But I now get this Software error trying to receive an order, whenever I use > the current "Receive" link or the new checkbox : > Can't locate Data/Printer.pm in @INC (you may need to install the > Data::Printer module) (@INC contains: /var/repositories/koha > /home/koha/perl5/lib/perl5/x86_64-linux-gnu-thread-multi > /home/koha/perl5/lib/perl5 /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 > /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 > /usr/local/lib/site_perl . /home/koha/koha-dev/var/lib/plugins) at > /var/repositories/koha/acqui/orderreceive.pl line 141. > BEGIN failed--compilation aborted at > /var/repositories/koha/acqui/orderreceive.pl line 141. > > No error when I switch back to master. > I stop the test at step 12, but for step 14, could we imagine to ass the > usual options "Check all / Uncheck all" we have on other Koha pages ? > I know it would be useful, especially if we use it combined with filters on > basket for example or author if a collection must be receipted. Sorry about that.. I'll fix that ASAP. Regarding check all / uncheck all I thought about that, but wasn't sure what the expected behaviour should be. Because this tables are paginated on server, it means that we do not have all rows when render. So this check all should check only the rows that are visible, or all rows that matches the filter? Maybe we could do something similar to what GMail does, to have a check all that only selects visible rows, and display a label or a button that says something like "Select all 523 rows". Anyhow, this should be a consistent behaviour for all datatables and deserves it's own bug and discussion. That's the reason why I didn't implement that.
Created attachment 112643 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t
Created attachment 112644 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql
Created attachment 112645 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref
Created attachment 112646 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Ok, Séverine, just removed all Data::Printer from code. Could you please try again? Thanks
Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 8179: Add tests Applying: Bug 8179: Add syspref to database Applying: Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration Applying: Bug 8179: Receive multiple orders Using index info to reconstruct a base tree... M koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt Falling back to patching base and 3-way merge... Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt Failed to merge in the changes.
Created attachment 112744 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t
Created attachment 112745 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql
Created attachment 112746 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref
Created attachment 112747 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
(In reply to Séverine Queune from comment #25) > Apply? [(y)es, (n)o, (i)nteractive] y > Applying: Bug 8179: Add tests > Applying: Bug 8179: Add syspref to database > Applying: Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference > configuration > Applying: Bug 8179: Receive multiple orders > Using index info to reconstruct a base tree... > M koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt > Falling back to patching base and 3-way merge... > Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt > CONFLICT (content): Merge conflict in > koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt > Failed to merge in the changes. Hello Séverine, could you please try once more?
Definitely bad luck on that one... Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 8179: Add tests Applying: Bug 8179: Add syspref to database Applying: Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference confi guration Applying: Bug 8179: Receive multiple orders fatal: sha1 information is lacking or useless (koha-tmpl/intranet-tmpl/prog/en/m odules/acqui/parcel.tt). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 8179: Receive multiple orders
(In reply to Séverine Queune from comment #31) > Definitely bad luck on that one... > > Apply? [(y)es, (n)o, (i)nteractive] y > Applying: Bug 8179: Add tests > Applying: Bug 8179: Add syspref to database > Applying: Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference > confi guration > Applying: Bug 8179: Receive multiple orders > fatal: sha1 information is lacking or useless > (koha-tmpl/intranet-tmpl/prog/en/m odules/acqui/parcel.tt). > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0001 Bug 8179: Receive multiple orders 20212 is currently FQA, that's why patches don't apply. We'll have to wait until it changes state.
Created attachment 114688 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t
Created attachment 114689 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql
Created attachment 114690 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref
Created attachment 114691 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Hi All, The Koha-US Acquisitions SIG is planning to sign off on this bug at our February 16 meeting. If you are interested in participating in this sign off, join us. The Zoom link can be found on the Koha-US.org website.
Please rebase for testing!
Created attachment 116582 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t
Created attachment 116583 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql
Created attachment 116584 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref
Created attachment 116585 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
(In reply to Andrew Fuerste-Henry from comment #38) > Please rebase for testing! Done!
Created attachment 116588 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116589 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116590 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116591 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
(In reply to Rhonda Kuiper from comment #37) > Hi All, > The Koha-US Acquisitions SIG is planning to sign off on this bug at our > February 16 meeting. If you are interested in participating in this sign > off, join us. The Zoom link can be found on the Koha-US.org website. Hi Rhonda, great that this bug is planed to be signed off. If I may, I'd suggest that before starting the meeting this steps should be ready: 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. I've tested this bug a couple of times and this steps are repetitive and tiresome. Cheers.
The list of items to be received hangs at Processing if any of your items/orders do not include a replacement price. Price math is inconsistent between receiving versions. I created an order using the sample data for My Vendor. The order shows: Quantity=1 Vendor price=3.00 Tax rate= 19.65 Discount= 0.1% The vendor shows: List item price includes tax: No Invoice item price includes tax: No Discount: 10.0 % Tax rate: 19.65 % If I click the old Receive button, orderreceive.pl shows: retail price: 3 replacement price: 3 budgeted cost: 2.70 actual cost: 2.70 If I select this order along with other and click Receive Selected, the receiving modal shows: retail price: 3.59 replacement price: 3 budgeted cost: 3.23 actual cost: 3.23055
Created attachment 116681 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116682 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116683 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116684 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Hi Andrew, first thanks for testing! (In reply to Andrew Fuerste-Henry from comment #49) > The list of items to be received hangs at Processing if any of your > items/orders do not include a replacement price. This one I could not reproduce.. I used the value 0, no value and even a blank space, but it worked for me.. could you give more detail about your test case? > Price math is inconsistent between receiving versions. I created an order > using the sample data for My Vendor. The order shows: > Quantity=1 > Vendor price=3.00 > Tax rate= 19.65 > Discount= 0.1% > > The vendor shows: > List item price includes tax: No > Invoice item price includes tax: No > Discount: 10.0 % > Tax rate: 19.65 % > > If I click the old Receive button, orderreceive.pl shows: > retail price: 3 > replacement price: 3 > budgeted cost: 2.70 > actual cost: 2.70 > > If I select this order along with other and click Receive Selected, the > receiving modal shows: > retail price: 3.59 > replacement price: 3 > budgeted cost: 3.23 > actual cost: 3.23055 This one was a bad check on the flag that determined if tax was included or not in prices, and always used tax included prices. Thanks for pointing this out. Could you please try once more and tell me about the first bug? Thanks!
To recreate the issue where receiving hangs on processing when missing a replacement price: 1: have a fresh Koha Testing Docker 2: apply patch, updatedatabase, restart_all 3: have a basket set to create item records on ordering 4: populate basket from a marc file, only setting price and fund for the items 5: close basket 6: click to Receive, create invoice 7: on parcel.pl, "Processing" alert never resolves The console shows: parcel.pl?invoiceid=1:810 Uncaught TypeError: Cannot read property 'format_price' of null at render (parcel.pl?invoiceid=1:810) at datatables.min_20.1200012.js:57 at Object.b.fnGetData (datatables.min_20.1200012.js:51) at B (datatables.min_20.1200012.js:56) at Ha (datatables.min_20.1200012.js:64) at P (datatables.min_20.1200012.js:68) at vb (datatables.min_20.1200012.js:79) at datatables.min_20.1200012.js:76 at i (datatables.min_20.1200012.js:74) at Object.success (datatables.min_20.1200012.js:75) And that error points toward: "data": "replacement_price", "render": function(data, type, row, meta) { return (row.replacement_price).format_price(); }, }, In the database, I see that aqorders.replacementprice is null for all of the orders I made. If I do an update to set aqorders.replacementprice=0, then the receiving page populates as expected.
Additional issue: 1 - on parcel.pl, check the checkboxes for one or more titles 2 - click the individual Receive link for one of the expected titles 3 - that takes you to orderreceive.pl for that individual title 4 - click Cancel 5 - when you get back to parcel.pl, the checkboxes you checked previously are still marked, but the Receive Selected button indicates you have zero titles selected. You must un-check and re-check the titles to get them to register. We should un-check those boxes if we leave and then return to the page.
A couple of typos. To recreate: 1 - select two or more orders to receive 2 - in the multi-receiving modal, update all but one of your orders to have received items 3 - save your changes in the modal 4 - back on the multi-receiving page, get these messages ("X" is the order number): Order X: No quantity to receive setted. No items will be created. Order X: An error cocurred while saving Those should be: Order 7: No quantity to receive set. No items will be created. Order 7: An error occurred while saving.
Created attachment 116942 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116943 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116944 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 116945 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
(In reply to Andrew Fuerste-Henry from comment #55) > To recreate the issue where receiving hangs on processing when missing a > replacement price: > 1: have a fresh Koha Testing Docker > 2: apply patch, updatedatabase, restart_all > 3: have a basket set to create item records on ordering > 4: populate basket from a marc file, only setting price and fund for the > items > 5: close basket > 6: click to Receive, create invoice > 7: on parcel.pl, "Processing" alert never resolves > The console shows: > parcel.pl?invoiceid=1:810 Uncaught TypeError: Cannot read property > 'format_price' of null > at render (parcel.pl?invoiceid=1:810) > at datatables.min_20.1200012.js:57 > at Object.b.fnGetData (datatables.min_20.1200012.js:51) > at B (datatables.min_20.1200012.js:56) > at Ha (datatables.min_20.1200012.js:64) > at P (datatables.min_20.1200012.js:68) > at vb (datatables.min_20.1200012.js:79) > at datatables.min_20.1200012.js:76 > at i (datatables.min_20.1200012.js:74) > at Object.success (datatables.min_20.1200012.js:75) > > And that error points toward: > "data": "replacement_price", > "render": function(data, type, row, meta) { > return (row.replacement_price).format_price(); > }, > }, > > In the database, I see that aqorders.replacementprice is null for all of the > orders I made. If I do an update to set aqorders.replacementprice=0, then > the receiving page populates as expected. Well, that was thorough! Thanks so much. This issue is not related to this bug, but to 20212 where the code was introduced. I created bug 27719 to fix this issue.
(In reply to Andrew Fuerste-Henry from comment #57) > A couple of typos. To recreate: > 1 - select two or more orders to receive > 2 - in the multi-receiving modal, update all but one of your orders to have > received items > 3 - save your changes in the modal > 4 - back on the multi-receiving page, get these messages ("X" is the order > number): > Order X: No quantity to receive setted. No items will be created. > Order X: An error cocurred while saving > > Those should be: > Order 7: No quantity to receive set. No items will be created. > Order 7: An error occurred while saving. Typos fixed!
(In reply to Andrew Fuerste-Henry from comment #56) > Additional issue: > 1 - on parcel.pl, check the checkboxes for one or more titles > 2 - click the individual Receive link for one of the expected titles > 3 - that takes you to orderreceive.pl for that individual title > 4 - click Cancel > 5 - when you get back to parcel.pl, the checkboxes you checked previously > are still marked, but the Receive Selected button indicates you have zero > titles selected. You must un-check and re-check the titles to get them to > register. > > We should un-check those boxes if we leave and then return to the page. Again, could not reproduce this error.. could you please copy/paste any errors that appear in browsers console? Thanks
Sorry Agustín, the patch needs a new rebase... CONFLICT (content): Merge conflict in t/db_dependent/Koha/Item.t error: Failed to merge in the changes. Patch failed at 0001 Bug 8179: Add tests
Created attachment 119178 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 119179 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 119180 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 119181 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Hi Agustín ! It's a pleasure to be able to test the full test plan, it's been a while I waited for it ! Everything works fine to me. I just have a suggestion for point 25. I get an alert for the different errors spotted during the saving but, as a user, it seemed a bit tiny to me, and as they disappear after the full job process, it seems very quick when there is just a few orders to register, so user can easily don't notice them I think. Could we imagine to have, for example, the yellow alert displayed once we're back on the receipt page, like we have in circulation pages ?
Sorry Agustín, I've just tested once more the subscription receipt, and realise the quantity received isn't taken into account : I ordered 12 as quantity and wanted to receive 1, after saving on modal, I still have the message "Receiving 12 out of 12", and order is set "Complete" after saving.
ok, last message (I hope... next time I'll try to a send a single feedback...). Columns in acqui/parcel.pl are not sortable anymore. I add a question about standing order : could it be interesting / is it possible to have informations about the previous receipt ? It's a feature we don't use, but while I tested it, I thought it might be helpful.
Do we see a chance for this in 21.05?
Created attachment 120620 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 120621 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 120622 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 120623 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Initial notes (more to follow): - Items WERE NOT created when receiving orders in a basket set to Create Items On Receiving for orders created either on an existing bib or a new bib (not tied to a subscription or purchase suggestion). - For orders tied to a purchase suggestion, the purchase suggestion link displays as "(suggestion #undefined)" and the link doesn't work (points to /cgi-bin/koha/suggestion/suggestion.pl?suggestionid=undefined&op=show) - on /acqui/orderreceive.pl?multiple_orders, the list of all selected order numbers is ugly. it shows like "[Vendor] [basket] (order #27667,27673)." With a lot of orders, it's not nice to look at. Do we need to list them all? Could we at least add spaces so it breaks across lines? - when increasing the quantity received for an order from a basket set to create items when cataloging, we got this warning: "Order 27690: Warning, you have entered more items than expected. Items will not be created." This is technically true, but seems unneeded. We didn't ever expect this order to make items.
On parcel.pl, when selecting orders to receive, we should have a "Select all" option to check the boxes for all orders currently onscreen. In this multi-receiving workflow, for order set to create items in cataloging, quantity received is defaulting to 0 and requiring the user to manually change it to match quantity ordered. When following the normal single order receiving workflow, Koha will assume that quantity received = quantity ordered if your basket was set to create items in cataloging. This change needs to be corrected.
Comment on attachment 120622 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration Review of attachment 120622 [details] [review]: ----------------------------------------------------------------- ::: koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref @@ +113,5 @@ > - pref: EmailAddressForSuggestions > class: email > + - > + - pref: AcqReceiveMultipleOrderLines > + defualt: no Typo in default
Sad to see this one stuck again. At the moment also doesn't apply cleanly.
Agreed - this functionality would save so much time for our staff. What is the best path forward to unstick this bug?
We do this currently via a separate app, but I'd love to see this in Koha.
Note that bug 32401 is removing header_filter from DT wrapper.
Just revisiting this bug since we talked about it today in a koha-US Acquisitions Special Interest Group meeting. All of the attendees agreed that this functionality would greatly help their libraries. Also, I see that this bug has 51 votes. Wondering what the next steps are to move this bug forward.
(In reply to Barbara Johnson from comment #85) > Just revisiting this bug since we talked about it today in a koha-US > Acquisitions Special Interest Group meeting. All of the attendees agreed > that this functionality would greatly help their libraries. Also, I see > that this bug has 51 votes. Wondering what the next steps are to move this > bug forward. I imagine koha-US might need to sponsor a developer to work on it.
(In reply to David Cook from comment #86) > (In reply to Barbara Johnson from comment #85) > > Just revisiting this bug since we talked about it today in a koha-US > > Acquisitions Special Interest Group meeting. All of the attendees agreed > > that this functionality would greatly help their libraries. Also, I see > > that this bug has 51 votes. Wondering what the next steps are to move this > > bug forward. > > I imagine koha-US might need to sponsor a developer to work on it. In reading through the bug it appears that Virginia Tech is sponsoring it.
(In reply to Barbara Johnson from comment #87) > In reading through the bug it appears that Virginia Tech is sponsoring it. It's been nearly 2 years, so I suppose the next step would be contacting Agustín Moyano and/or Virginia Tech about progress then. Many of us have a lot of tickets open on Bugzilla, so it can be hard to keep track of them all. Could be worth sending an email directly.
Created attachment 148215 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 148216 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 148217 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 148218 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 148233 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University
Created attachment 148284 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 148285 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 148286 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 148287 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 148288 [details] [review] Bug 8179: Modernize atomic update Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Minor tidy and a simple follow-up to avoid minor QA issues.
Thanks for taking the time to rebase, Agustin.
Thanks to Agustin for rebasing this one so that it could be tested. I noticed that Tomás signed off on this one (thank you!) but the status hadn't been changed so I updated it to signed off. Looking forward to this functionality!
We'd like a third party to do the sign-off.
Thanks Tomás - that's good to know. The koha-US Acquisitions SIG will be glad to do this.
Created attachment 148521 [details] [review] Bug 32983: Fix dropdown list when search for EBSCO's packages Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148522 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148523 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148524 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148525 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148526 [details] [review] Bug 8179: Modernize atomic update Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
https://snipboard.io/CmFqJD.jpg Edit link gives me Uncaught TypeError: item._authorised_values is undefined Was it working yesterday and not today? Also, why a pref?
dataTables.select.min.js, select.dataTables.min.css => Are you really using them? I am not seeing them in the rest of the patch.
(In reply to Jonathan Druart from comment #111) > dataTables.select.min.js, select.dataTables.min.css > > => Are you really using them? I am not seeing them in the rest of the patch. I mean, I do see the include in the DOM, not where DT is actually using it.
Can we get a signoff from the sponsor?
Created attachment 148685 [details] Save Message When attempting to multi receive orders where the basket was created using "create item when ordering", step number 16 (clicking on the edit link) does not work. No modal window appears. Since we couldn't click edit, we clicked save (Screenshot attached) when attempting to save during the receiving process. When receiving baskets where the item is created when receiving, the item is actually never created. You can multi receive orders, but not item is actually created. When multi receiving baskets where you create an item when cataloging is successful.
Created attachment 148981 [details] [review] Bug 8179: Add tests This patch adds tests in: * t/db_dependent/Koha/Acquisition/Fund.t * t/db_dependent/Koha/Acquisitoin/Order.t * t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148982 [details] [review] Bug 8179: Add syspref to database This patch adds the AcqReceiveMultipleOrderLines syspref by atomicupdate and in sysprefs.sql Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148983 [details] [review] Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration This patch adds AcqReceiveMultipleOrderLines to koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148984 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148985 [details] [review] Bug 8179: Modernize atomic update Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Created attachment 148986 [details] [review] Bug 8179: Adapt to new +strings embed While we rebased correctly this old patchset, we still had to make sure we are using both the +strings in embed (instead of the x-koha-av header) and the _strings key instead of the original _authorised_values one. This patch adjusts that. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We should not need the syspref, neither the 2 views for receiving. If we receive only one we could display the same form than we use for multi receiving.
(In reply to Jonathan Druart from comment #121) > We should not need the syspref, neither the 2 views for receiving. If we > receive only one we could display the same form than we use for multi > receiving. +1
In testing this bug, I found the multi-receiving option for the basket "create items on receiving" to not work as expected. I have three orders for my basket, creating items on receiving. Each order has 2 items in it. When I click the three orders from this basket, I am brought to a model which displays the titles and the number I should be receiving on each title. My option is to click edit to the far right of the screen. This model pops up in the tab "info'. I click over to the Item tab, and am brought to an item template, to create the item that I am receiving. Below the item template, that I have options, Add Item, Clear, Add multiple Items (which are choices one has generally). Further down, I have choices, Previous, Close, Save Changes and Next. When I fill out my item, I can choose to Save Changes, but my item is not received. If I am receiving multi, I choose Next and fill out the next item template, but again, my receiving is not recorded.
Created attachment 151026 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
1. - b_sel => ( $budget->{budget_id} == $order->budget_id ) ? 1 : 0, + # b_sel => ( $budget->{budget_id} == $order->budget_id ) ? 1 : 0, Then remove ;) 2. + creator: + type: + - object + - "null" + description: Patron that created the order We could tell here we expect an object representing a patron 3. + - items.home_branch + - items.holding_branch + - items.itemtype Shouldn't they use the "fixed names"? home_library, item_type? It means to add more methods, and tests, but once it's in the spec it will be hard to modify. Not blocker as I guess we are doing that in other places. 4. https://snipboard.io/SvHwAn.jpg The "Change currency" checkbox is not aligned properly And it's actually not working: * edit * Set actual cost, check "change currency", select a currency, save * edit again => Values are not saved, you are actually breaking bug 25655. Also I have seen "NaN" generated in actual cost but not sure when/how. And finally, values are not saved in the DB (invoice_currency, invoice_unitprice). 5. Partial receive does not seem to work I ordered 3, received 1, receiving again: "Receiving 0 out of 2" => OK Click edit => There are 3 items in the items table 6. "Date received:" does not have flatpickr applied 7. Fund is not marked "required" like before 8. We lost the "show active" checkbox next to the fund list 9. There are missing spaces after numbers "Retail price: 0.00(adjusted for USD, tax exclusive)" 10. + <th><!--input type="checkbox" id="selectAll"/--></th> Do we want that? 11. JS code in parcel.tt use 2 spaces indentation instead of 4 12. I noticed 2 parallel request to parcel.pl?invoiceid=1 at the end of the process, and one of them is aborted. This is what is in the console: https://snipboard.io/IKwoVP.jpg 13. comment 111 and comment 112 still need an answer. I don't understand how dataTables.select.min.js, select.dataTables.min.css is useful here. Is that the row.select() and row.deselect() statements in parcel.tt? If so, what are they doing? I removed them and didn't see any issues. 14. There are several parts of the JS code in orderreceive.tt that are commented, if we don't need them we should remove them. 15. I think we should widen the modal. The item form is not displayed nicely https://snipboard.io/VIKAgY.jpg 16: not sure it's a blocker: When you select some orders, the table on the order receive page has "Showing 1 to 1 of 1 entries (filtered from 3 total entries)" But there is no way to display them all. I understand why and what it implies, just noting. 17. Another "just noting": the code (introduced by bug 20212 I think) related to biblio.suggestions.suggester is bad and should have been simplified before we did all this. I submitted a patch yesterday to remove GetSuggestionInfoFromBiblionumber, it's on bug 28844.
(In reply to Jonathan Druart from comment #125) > 1. > - b_sel => ( $budget->{budget_id} == $order->budget_id ) ? 1 : 0, > + # b_sel => ( $budget->{budget_id} == $order->budget_id ) ? 1 : 0, > > Then remove ;) Agreed. > 2. > + creator: > + type: > + - object > + - "null" > + description: Patron that created the order > > We could tell here we expect an object representing a patron It doesn't work. You cannot put a $ref and 'null', unfortunately. OpenAPI v3 might make it possible. > 3. > + - items.home_branch > + - items.holding_branch > + - items.itemtype > > Shouldn't they use the "fixed names"? home_library, item_type? That's a leftover, not even used and prior to the +strings addition. Will remove. > 4. https://snipboard.io/SvHwAn.jpg > The "Change currency" checkbox is not aligned properly > And it's actually not working: > * edit > * Set actual cost, check "change currency", select a currency, save > * edit again > => Values are not saved, you are actually breaking bug 25655. > Also I have seen "NaN" generated in actual cost but not sure when/how. > > And finally, values are not saved in the DB (invoice_currency, > invoice_unitprice). Will check. The most recent iteration got them flawed. > 5. Partial receive does not seem to work > I ordered 3, received 1, receiving again: > "Receiving 0 out of 2" => OK > Click edit > => There are 3 items in the items table Noted, it's a problem with how the post form is built (the items_to_receive array arrives empty to finishreceive.pl). Working on it > 6. "Date received:" does not have flatpickr applied > > 7. Fund is not marked "required" like before > > 8. We lost the "show active" checkbox next to the fund list > > 9. There are missing spaces after numbers "Retail price: 0.00(adjusted for > USD, tax exclusive)" > > 10. > + <th><!--input type="checkbox" id="selectAll"/--></th> > > Do we want that? > > 11. JS code in parcel.tt use 2 spaces indentation instead of 4 > > 12. I noticed 2 parallel request to parcel.pl?invoiceid=1 at the end of the > process, and one of them is aborted. This is what is in the console: > https://snipboard.io/IKwoVP.jpg > > 13. comment 111 and comment 112 still need an answer. > I don't understand how dataTables.select.min.js, select.dataTables.min.css > is useful here. Is that the row.select() and row.deselect() statements in > parcel.tt? If so, what are they doing? I removed them and didn't see any > issues. > > 14. There are several parts of the JS code in orderreceive.tt that are > commented, if we don't need them we should remove them. > > 15. I think we should widen the modal. The item form is not displayed nicely > https://snipboard.io/VIKAgY.jpg > > 16: not sure it's a blocker: When you select some orders, the table on the > order receive page has "Showing 1 to 1 of 1 entries (filtered from 3 total > entries)" > But there is no way to display them all. I understand why and what it > implies, just noting. > > 17. Another "just noting": the code (introduced by bug 20212 I think) > related to biblio.suggestions.suggester is bad and should have been > simplified before we did all this. I submitted a patch yesterday to remove > GetSuggestionInfoFromBiblionumber, it's on bug 28844.
Created attachment 151086 [details] [review] Bug 8179: Make partial receive work correctly Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151087 [details] [review] Bug 8179: Remove commented code Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151088 [details] [review] Bug 8179: Remove leftover/not used embed definitions Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151089 [details] [review] Bug 8179: Fix JS indentation in parcel.tt Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151092 [details] [review] Bug 8179: Cosmetic changes Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151093 [details] [review] Bug 8179: Fund required
Created attachment 151137 [details] [review] Bug 8179: Receive multiple orders This patch implements the code to allow a patron to receive multiple orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page To test: 1. apply all patches 2. updatedatabase 3. Go to system preferences and allow AcqReceiveMultipleOrderLines 4. In acquisitions module, create a vendor if you don't have one and add 3 baskets.. one with create items on ordering, one with create items on receiving and finally one with create items when cataloguing 5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods. 6. Close all baskets and receive shipment. CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected" 7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page 8. Check some of the checkboxes CHECK => "Receive selected" button shows how many rows are selected 9. Go to the next page and select some more rows CHECK => Changing page does not modify how many rows where selected 10. Go back to previous page CHECK => Previously selected rows are still selected 11. Reload the page to deselect all rows 12. Select only one row and click on "Receive selected" button CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked. 13. Click on cancel to go back to parcel.pl page 14. Select all rows (even the ones from the next page of the table) and click on "Receive selected" CHECH => In orderreceive.pl page there is a table with all selected rows 15. Ensure table has more than one page, as in step 7 16. Click on the "edit" link in the last row of the current page CHECK => A modal window is displayed with 4 tabs within: Info, Accounting, Receipt history and Items CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos order, 'Cancel' to close the modal without keeping modifications, 'Save' to close modal keeping modifications and 'Next' to go to the next order CHECK => Even that we are at the end of the current page, 'Next' button is still available 17. Click on 'Next' button CHECK => The table behind the modal now displays the next page, and the modal was not closed 18. Click on 'Previous' CHECK => The table behind the modal went back to the first page, and the modal was not closed 19. Click on 'Previous' button till you reach the first row of the first page CHECK => Only when you reach the first row of the first page 'Previous' button gets disabled 20. Click on 'Next' button till you reach the last row of the last page CHECK => Only when you reach the last button of the last page 'Next' button gets disabled 21. Check that behaviour for the different types of order are still the same a. For orders that where created through suggestion, check that the suggestion info is present in Info tab. If when suggestion was accepted you set a reason, a dropdown to change the reason shoul display also. b. For orders that where created through subscriptions, check that the Items tab is disabled, and the Receipt history is enabled. On accounting tab you should be able to change quantity ordered. If there were less items received than ordered, the next time you receive this order the child order generated from this one shoul appear in receipt history. c. For orders that don't come from subscription and creates there items on ordering, Receipt history should be disabled, and a table with prefilled items shold appear in the Items tab. You can edit them and the changes should appear in the item's row. d. For orders that don't come from subscription and creates there items on receiving, Receipt history should be disabled, and a form to create the items should appear in Items tab. When you add an item a table should appear. e. For orders that don't come from subscription and creates there ites on cataloguing, Receipt history and Items tabs should be disabled. f. Any changes made in quantity (received or ordered) or funds in the modal should be reflected in the table if you click save from the modal. 22. Once you've done all you checking and verifications click save 23. While saving a progress bar should appear 24. If no error was detected, you should be redirected back to parcel.pl page 25. If an error or warning was detected (like there is an order with 0 items to receive) the save button should be disabled and warnings are dispayed. 26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t Sponsored-by: Virginia Polytechnic Institute and State University Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151138 [details] [review] Bug 8179: Make partial receive work correctly Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151139 [details] [review] Bug 8179: Remove commented code Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151140 [details] [review] Bug 8179: Remove leftover/not used embed definitions Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151141 [details] [review] Bug 8179: Fix JS indentation in parcel.tt Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151142 [details] [review] Bug 8179: Cosmetic changes Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151143 [details] [review] Bug 8179: Fund required Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151144 [details] [review] Bug 8179: (QA follow-up) Date received should default to today Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 151145 [details] [review] Bug 8179: (QA follow-up) Fix currency conversion Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I gone over the open issues and everything looks good for me except for the currency issue and the received date, which I've supplied fixes for!
I was reviewing at the same time as Kyle by the looks.. didn't make it as far as he did clearly as he did some follow-ups. Generally it's all looking good.. I'm happy to lend a hand on any fixes needed if we missed something. Great work guys.
Created attachment 151163 [details] [review] Bug 8179: (follow-up) Fix currency change and remove datatables select
Pushed to master for 23.05. Nice work everyone, thanks!
Can we get an updated test plan? It looks like for example that the system preference in step 3 got lost.
(In reply to Katrin Fischer from comment #146) > Can we get an updated test plan? It looks like for example that the system > preference in step 3 got lost. It is enabled, and no action required to use the feature.
Created attachment 151250 [details] [review] Bug 8179: Remove ref to select.dataTables.min.css
(In reply to Jonathan Druart from comment #148) > Created attachment 151250 [details] [review] [review] > Bug 8179: Remove ref to select.dataTables.min.css Pushed to master.
(In reply to Jonathan Druart from comment #125) > 8. We lost the "show active" checkbox next to the fund list Still missing, and the fund list is empty!
When doing a partial receive, "Actual cost" should be prefilled with the value of the first order. It does not work when another currency is used.
Created attachment 151367 [details] [review] Bug 8179: Add vendor id on breadcrumb link Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151431 [details] [review] Bug 8179: (follow-up) Restore funds dropdown and checkbox This patch reintroduces the dropdown that got lost in some refactoring of the patchset. It also introduces a couple minor fixes. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pushed the last follow-up for the sake of having the strings in place. Lucas was looking at styling it better. Remaining issues should be handled in follow-up bugs for clarity.
A quick note, it seems that we are using #jobpanel for the progress bar, which is the old way. Now we should prefer job_progress.inc.
New feature. Not pushed to 22.11.07.