[Bug 33864] New: Modal broken when "AcqCreateItem" set to "cataloguing"
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Bug ID: 33864 Summary: Modal broken when "AcqCreateItem" set to "cataloguing" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: tomascohen@gmail.com Reporter: nugged@gmail.com QA Contact: testopia@bugs.koha-community.org Blocks: 33784 To test: 0. Set syspref to "AcqCreateItem" set to "cataloguing" ( /cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=AcqCreateItem ) 1. Create a basket 1.1. Go to Acquisitions 1.2. Search for a vendor 1.3. Click New > Basket 1.4. Fill out the basket form 1.5. Click Save 2. Add at least one order to the basket 2.1. Click Add to basket 2.2. Click From a new (empty) record 2.3. Fill out the order form 2.4. Click Save 3. Click Close basket and confirm 4. Click Receive shipments 5. THE PROBLEM IS HERE: - "Confirm" button never gets enabled even if we fill in the form fields, - "Date received:" not prefilled but better should be filled (auto? or from DB?), - "Quantity received:" not prefilled, but on 22.11 it was "1" by default and anyway saved clicks for librarians, and maybe it also should be filled with some cleverly even in "AcqCreateItem" set to "cataloguing" (=1?) NOTE: "AcqCreateItem" set to "cataloguing" is used in our libraries because they receive newspapers and magazines which not then have physical items but by quantity per-biblio, that's why and hos this option is used in our case. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33784 [Bug 33784] Save clicks on single order receive -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #1 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 151799 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151799&action=edit Bug 33864: Set default date in all acqcreateitem scenarios On b0aab2aeef9a025d3907d0b723b5ea71eaf94542 the flatpickr default to 'today' was restored, but only for acqcreateitem='ordering'. This patch moves the initialization to a different stop for broader reach. To test: 1. Have 3 baskets on with each setting: - create_item = 'cateloguing' - create_item = 'ordering' - create_item = 'receiving' 2. Close those baskets 3. Go to 'Receive shipments' 4. Choose things from the 3 baskets and then 'Receive selected' 5. Navigate through the different orders => FAIL: Only the one that has items created on ordering has the date filled by default 6. Apply this patch 7. Reload the page 8. Repeat 5 => SUCCESS: Dates are pre-filled! 9. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #2 from Andrew Nugged <nugged@gmail.com> --- Extra note: in 22.11 quantity was hard coded to 1 when no quantityreceived and the date to "today" if there's no "datereceived" property for the order, and that was more comfortable for our librarians than "0"/"empty". -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 151803 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151803&action=edit Bug 33864: Better handling of confirmation button This patch corrects the behavior of the 'Confirm' button on the three possible scenarios regarding item creation. Ordering: - Quantity gets locked (only changeable when selecting items) - 'Confirm' disabled, only gets enabled if quantity > 0 Receiving: - Quantity gets locked (only changeable when creating items) - 'Confirm' disabled, only gets enabled if quantity > 0 Cataloguing: - It now defaults to 1 - 'Confirm' enabled by default (because of 1) if quantity is set to 0, it gets disabled. To test: 1. Verify the described behavior with the sample orders for the previous patch. => SUCCESS: It does the job! Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agustinmoyano@theke.io, | |jonathan.druart+koha@gmail. | |com, | |katrin.fischer@bsz-bw.de, | |kyle@bywatersolutions.com, | |michaela.sieber@kit.edu, | |nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Sam Lau <samalau@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply CC| |samalau@gmail.com --- Comment #4 from Sam Lau <samalau@gmail.com> --- error: could not build fake ancestor Patch failed at 0001 Bug 33864: Set default date in all acqcreateitem scenarios -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Sam, please make sure you do a git pull before trying to apply patches, Koha is moving fast. Patches apply ok on most recent master branch, testing now. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 2 things: 1) The date received patch works fine. No complaints. 2) I have an issue with quantity received: I tested in 20.11.19 and the quantity is set to 0 zero there. Could setting it to 1 have been a local customization? I am in favor of leaving it at 0 and keeping the existing behavior of older versions (I couldn't verify in 22.05) BUT: if we pre-populated I think 1 would still be wrong, it should be pre-set with quantity ordered. 3) BLOCKER: There is an issue if you have a basket with * item create on order * standing order You'll have an empty item form on the left and quantity received is BLOCKED. There is no way to receive. This combination is kinda odd, but currently doesn't cause issues, we can expect libraries having 'order' as standard to forget to change it and they won't be able to fix this in the GUI as the item create value can only be set when the basket is created. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 4) BLOCKER: if item create 'on receive': Don't lock 'Quantity received'. The existing behaviour is like this: * Enter the number received if you don't care which items will be selected. X checkboxes will be set on the items from top to bottom. * Check uncheck items and the quantity will be adjusted accordingly. The first use case is the one used more often and it's no broken. This means if a library orders something in big numbers, they need to click the checkbox for each and every item (and hate it ;) ) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151803|0 |1 is obsolete| | --- Comment #8 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 151811 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151811&action=edit Bug 33864: Better handling of confirmation button This patch corrects the behavior of the 'Confirm' button on the three possible scenarios regarding item creation. Ordering: - Quantity gets locked (only changeable when selecting items) - 'Confirm' disabled, only gets enabled if quantity > 0 Receiving: - Quantity gets locked (only changeable when creating items) - 'Confirm' disabled, only gets enabled if quantity > 0 Cataloguing: - It now defaults to 1 - 'Confirm' enabled by default (because of 1) if quantity is set to 0, it gets disabled. To test: 1. Verify the described behavior with the sample orders for the previous patch. => SUCCESS: It does the job! Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #9 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Katrin Fischer from comment #6)
2 things:
1) The date received patch works fine. No complaints.
Great.
2) I have an issue with quantity received: I tested in 20.11.19 and the quantity is set to 0 zero there. Could setting it to 1 have been a local customization? I am in favor of leaving it at 0 and keeping the existing behavior of older versions (I couldn't verify in 22.05) BUT: if we pre-populated I think 1 would still be wrong, it should be pre-set with quantity ordered.
Separate bug I think, we checked this is how it works in 22.11.
3) BLOCKER: There is an issue if you have a basket with * item create on order * standing order You'll have an empty item form on the left and quantity received is BLOCKED. There is no way to receive. This combination is kinda odd, but currently doesn't cause issues, we can expect libraries having 'order' as standard to forget to change it and they won't be able to fix this in the GUI as the item create value can only be set when the basket is created.
Can you check with the new version? (In reply to Katrin Fischer from comment #7)
4) BLOCKER: if item create 'on receive': Don't lock 'Quantity received'. The existing behaviour is like this: * Enter the number received if you don't care which items will be selected. X checkboxes will be set on the items from top to bottom. * Check uncheck items and the quantity will be adjusted accordingly. The first use case is the one used more often and it's no broken. This means if a library orders something in big numbers, they need to click the checkbox for each and every item (and hate it ;) )
Can you check with the new version? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Andrew Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|33784 | Depends on| |33784 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33784 [Bug 33784] Save clicks on single order receive -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Andrew Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |8179 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 [Bug 8179] Receiving multiple order lines at once -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151799|0 |1 is obsolete| | --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 151812 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151812&action=edit Bug 33864: Set default date in all acqcreateitem scenarios On b0aab2aeef9a025d3907d0b723b5ea71eaf94542 the flatpickr default to 'today' was restored, but only for acqcreateitem='ordering'. This patch moves the initialization to a different stop for broader reach. To test: 1. Have 3 baskets on with each setting: - create_item = 'cateloguing' - create_item = 'ordering' - create_item = 'receiving' 2. Close those baskets 3. Go to 'Receive shipments' 4. Choose things from the 3 baskets and then 'Receive selected' 5. Navigate through the different orders => FAIL: Only the one that has items created on ordering has the date filled by default 6. Apply this patch 7. Reload the page 8. Repeat 5 => SUCCESS: Dates are pre-filled! 9. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151811|0 |1 is obsolete| | --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 151813 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151813&action=edit Bug 33864: Better handling of confirmation button This patch corrects the behavior of the 'Confirm' button on the three possible scenarios regarding item creation. Ordering: - Quantity gets locked (only changeable when selecting items) - 'Confirm' disabled, only gets enabled if quantity > 0 Receiving: - Quantity gets locked (only changeable when creating items) - 'Confirm' disabled, only gets enabled if quantity > 0 Cataloguing: - It now defaults to 1 - 'Confirm' enabled by default (because of 1) if quantity is set to 0, it gets disabled. To test: 1. Verify the described behavior with the sample orders for the previous patch. => SUCCESS: It does the job! Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> https://bugs.koha-community.org/show_bug.cgi?id=33846 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #12 from Andrew Nugged <nugged@gmail.com> --- but to say how it behave before 23.05 - on our 22.11 there was such code: [% IF ( order.quantityreceived ) %] ... [% ELSE %] <input type="text" inputmode="numeric" pattern="[0-9]*" id="quantity" size="20" name="quantityrec" value="1" /> <input id="origquantityrec" readonly="readonly" type="hidden" name="origquantityrec" value="0" /> [% END %] i.e. hardcoded `value="1"`. And I see same on 22.05 and since ages: Bug 5917 : Converted templates 77b64098 Year 2011 [% IF ( items ) %] <input id="quantityrec" READONLY type="text" size="20" name="quantityrec" value="1" /> [% ELSE %] <input id="quantityrec" type="text" size="20" name="quantityrec" value="1" /> [% END %] ======
(In reply to Katrin Fischer from comment #6) I am in favor of leaving it at 0 and keeping the existing behavior of older versions (I couldn't verify in 22.05) BUT: if we pre-populated I think 1 would still be wrong, it should be pre-set with quantity ordered.
It would be a time saver if it were prepopulated with the quantity ordered, but at least having it "1" covers most cases our librarians receiving something 1, so good point to have it more clever but not zero. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #13 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 151816 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151816&action=edit Bug 33864: Restore inputmode="numeric" (bug 28283) Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33867 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33867 [Bug 33867] Quantity received should default to quantity ordered when creating items on cataloguing -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Modal broken when |Problems in order receive |"AcqCreateItem" set to |modal |"cataloguing" | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #14 from Slava Shishkin <slavashishkin@gmail.com> --- Created attachment 151821 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151821&action=edit Bug 33864: Fix to store shadow value for input as well -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |slavashishkin@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151821|0 |1 is obsolete| | --- Comment #15 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 151824 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151824&action=edit Bug 33864: Trigger the 'change' event when setting quantity Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #16 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Can you explain the latest changes for retesting? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #17 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Katrin Fischer from comment #16)
Can you explain the latest changes for retesting?
The latest patch from Slava then replaced by mine, were talked about on Telegram... When you're using the 'cataloguing' setting, the input is correctly filled with '1' (as per our agreement) but any changes to the UI, should be stored in the underlying JS object that tracks the state of the request. When setting it, I force the 'change()' event, so that internal synced happens (by means of an event handler defined previously for the 'change' event. If you want to test, verify that without the patch, '1' is set, and when you want to confirm, a brief message about receiving less than 1 is incorrect, and then the parcel.pl table displays nothing got received. With the patch, that's fixed: no error, and the thing is received. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Andrew Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Andrew Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151812|0 |1 is obsolete| | Attachment #151813|0 |1 is obsolete| | Attachment #151816|0 |1 is obsolete| | Attachment #151824|0 |1 is obsolete| | --- Comment #18 from Andrew Nugged <nugged@gmail.com> --- Created attachment 151852 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151852&action=edit Bug 33864: Set default date in all acqcreateitem scenarios On b0aab2aeef9a025d3907d0b723b5ea71eaf94542 the flatpickr default to 'today' was restored, but only for acqcreateitem='ordering'. This patch moves the initialization to a different stop for broader reach. To test: 1. Have 3 baskets on with each setting: - create_item = 'cateloguing' - create_item = 'ordering' - create_item = 'receiving' 2. Close those baskets 3. Go to 'Receive shipments' 4. Choose things from the 3 baskets and then 'Receive selected' 5. Navigate through the different orders => FAIL: Only the one that has items created on ordering has the date filled by default 6. Apply this patch 7. Reload the page 8. Repeat 5 => SUCCESS: Dates are pre-filled! 9. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Andrew Nugged <nugged@gmail.com> https://bugs.koha-community.org/show_bug.cgi?id=33846 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #19 from Andrew Nugged <nugged@gmail.com> --- Created attachment 151853 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151853&action=edit Bug 33864: Better handling of confirmation button This patch corrects the behavior of the 'Confirm' button on the three possible scenarios regarding item creation. Ordering: - Quantity gets locked (only changeable when selecting items) - 'Confirm' disabled, only gets enabled if quantity > 0 Receiving: - Quantity gets locked (only changeable when creating items) - 'Confirm' disabled, only gets enabled if quantity > 0 Cataloguing: - It now defaults to 1 - 'Confirm' enabled by default (because of 1) if quantity is set to 0, it gets disabled. To test: 1. Verify the described behavior with the sample orders for the previous patch. => SUCCESS: It does the job! Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Andrew Nugged <nugged@gmail.com> https://bugs.koha-community.org/show_bug.cgi?id=33846 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #20 from Andrew Nugged <nugged@gmail.com> --- Created attachment 151854 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151854&action=edit Bug 33864: Restore inputmode="numeric" (bug 28283) Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Andrew Nugged <nugged@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #21 from Andrew Nugged <nugged@gmail.com> --- Created attachment 151855 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151855&action=edit Bug 33864: Trigger the 'change' event when setting quantity Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Andrew Nugged <nugged@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151852|0 |1 is obsolete| | --- Comment #22 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 151856 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151856&action=edit Bug 33864: Set default date in all acqcreateitem scenarios On b0aab2aeef9a025d3907d0b723b5ea71eaf94542 the flatpickr default to 'today' was restored, but only for acqcreateitem='ordering'. This patch moves the initialization to a different stop for broader reach. To test: 1. Have 3 baskets on with each setting: - create_item = 'cateloguing' - create_item = 'ordering' - create_item = 'receiving' 2. Close those baskets 3. Go to 'Receive shipments' 4. Choose things from the 3 baskets and then 'Receive selected' 5. Navigate through the different orders => FAIL: Only the one that has items created on ordering has the date filled by default 6. Apply this patch 7. Reload the page 8. Repeat 5 => SUCCESS: Dates are pre-filled! 9. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Andrew Nugged <nugged@gmail.com> https://bugs.koha-community.org/show_bug.cgi?id=33846 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151853|0 |1 is obsolete| | --- Comment #23 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 151857 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151857&action=edit Bug 33864: Better handling of confirmation button This patch corrects the behavior of the 'Confirm' button on the three possible scenarios regarding item creation. Ordering: - 'Confirm' disabled, only gets enabled if quantity > 0 Receiving: - Quantity gets locked (only changeable when creating items) - 'Confirm' disabled, only gets enabled if quantity > 0 Cataloguing: - It now defaults to 1 - 'Confirm' enabled by default (because of 1) if quantity is set to 0, it gets disabled. To test: 1. Verify the described behavior with the sample orders for the previous patch. => SUCCESS: It does the job! Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Andrew Nugged <nugged@gmail.com> https://bugs.koha-community.org/show_bug.cgi?id=33846 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151854|0 |1 is obsolete| | --- Comment #24 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 151858 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151858&action=edit Bug 33864: Restore inputmode="numeric" (bug 28283) Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Andrew Nugged <nugged@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151855|0 |1 is obsolete| | --- Comment #25 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 151859 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151859&action=edit Bug 33864: Trigger the 'change' event when setting quantity Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Andrew Nugged <nugged@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 --- Comment #26 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I did another round of testing and adjusted the test plan of the second patch (we no longer lock quantity for 'create on order') -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33863 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33863 [Bug 33863] On receive "change currency" is always checked -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |23.05.00 released in| | --- Comment #27 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Pushed to master for 23.05.00 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Bug 33864 depends on bug 33784, which changed state. Bug 33784 Summary: Save clicks on single order receive https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33784 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |matt.blenkinsop@ptfs-europe | |.com Status|Pushed to master |RESOLVED --- Comment #28 from Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> --- Dependencies missing - not backporting to 22.11.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |35004 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35004 [Bug 35004] Error about no quantity set on acquisitions order receive confirmation. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org