[Bug 25039] New: Move new due calculation to Koha::Checkout
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Bug ID: 25039 Summary: Move new due calculation to Koha::Checkout Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Tools Assignee: tomascohen@gmail.com Reporter: jonathan.druart@bugs.koha-community.org QA Contact: testopia@bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 102273 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102273&action=edit Bug 25039: Move new due date calculation to Koha::Checkout This is a follow-up patch of bug 25020. This patch adds a new method Koha::Checkout->shift_due_date that accepts the same parameters we provide in the form. It catches bad scenarios (type errors, passing both parameters when only one is accepted, and so on). Date manipulation is tested so time is kept and resulting dates are correct. The controller script is cleaned a bit to use the introduced method. I do this because: - We really need tests for this and doing it with selenium is no-end - I see a use for this new method for encapsulating behaviours, for example we might want to add Calendar support for the 'days' use case, and having the method here assures we will have tests, etc. To test: 1. Apply this patches 2. Repeat the original test plan => SUCCESS: Everything works as expected 3. Run: $ kshell k$ prove t/db_dependent/Koha/Checkout.t => SUCCESS: Tests pass! 4. 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=25039 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |25020 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25020 [Bug 25020] Extending due dates to a specified date should preserve time portion of original due date -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #2 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> ---
From bug 25020 comment 6:
""" A quick note, I think this kind of tests is overkill and not needed: + Koha::Exceptions::WrongParameter->throw( + "'hard_due_date' must be a DateTime object" + ) unless $hard_due_date->isa('DateTime'); + + $due_date = $hard_due_date->clone->set( + hour => $due_date->hour, + minute => $due_date->minute, + second => $due_date->second + ); + } + else { + Koha::Exceptions::WrongParameter->throw( + "'days' must be an integer" + ) unless looks_like_number($days); + $due_date->add( days => $days ); Developers will get an error anyway if $days is not an integer (DateTime will raise its own meaningful exception), or $hard_due_date is not a DateTime. """ -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #2)
From bug 25020 comment 6:
""" A quick note, I think this kind of tests is overkill and not needed:
+ Koha::Exceptions::WrongParameter->throw( + "'hard_due_date' must be a DateTime object" + ) unless $hard_due_date->isa('DateTime');
I disagree. If we require a specific data type on the 'hard_due_date' param, we need to check it, otherwise we could have bad code working correctly in 'some' circumstances but failing of edge cases.
+ Koha::Exceptions::WrongParameter->throw( + "'days' must be an integer" + ) unless looks_like_number($days); + $due_date->add( days => $days );
Developers will get an error anyway if $days is not an integer (DateTime will raise its own meaningful exception), or $hard_due_date is not a DateTime
I agree here, but we try to translate those exceptions into Koha::Exceptions, right? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #4 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I don't think we should start testing all types of all our parameters, that will be a pain. We shoult assume $patron is a Koha::Patron, and *date* is a DateTime. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #5 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #4)
I don't think we should start testing all types of all our parameters, that will be a pain. We shoult assume $patron is a Koha::Patron, and *date* is a DateTime.
I you are implying that this shouldn't be enforced in a coding guideline and QA, I *might* agree. But if a bug implements that, I wouldn't reject it because of that. That said, we've been doing this for a while when we thought it was relevant or a good way to notify the caller so they take actions depending on the failure. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com, | |martin.renvoize@ptfs-europe | |.com, | |nick@bywatersolutions.com --- Comment #6 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Tomás Cohen Arazi from comment #5)
(In reply to Jonathan Druart from comment #4)
I don't think we should start testing all types of all our parameters, that will be a pain. We shoult assume $patron is a Koha::Patron, and *date* is a DateTime.
I you are implying that this shouldn't be enforced in a coding guideline and QA, I *might* agree. But if a bug implements that, I wouldn't reject it because of that.
That said, we've been doing this for a while when we thought it was relevant or a good way to notify the caller so they take actions depending on the failure.
In this specific case we could just make DateTime explode in a try/catch block inside this method and raise the same exceptions. Generally speaking, it is debatable if we should catch them locally or let them through. I think it is saner for writing the controllers if we raise our appropriate exceptions. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff --- Comment #7 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #2)
+ else { + Koha::Exceptions::WrongParameter->throw( + "'days' must be an integer" + ) unless looks_like_number($days); + $due_date->add( days => $days );
Developers will get an error anyway if $days is not an integer (DateTime will raise its own meaningful exception), or $hard_due_date is not a DateTime.
I tried removing the checks, and the results are not cool: - Removing the check for DateTime object => found: Can't locate object method "clone" via package "cat" (perhaps you forgot to load "cat"?) at /kohadevbox/koha/Koha/Checkout.pm line 190. - Removing the check for number => found: normal exit, and a simple warning: Argument "dog" isn't numeric in addition (+) at /usr/lib/x86_64-linux-gnu/perl5/5.24/DateTime/Duration.pm line 74. So, from the developer POV, in this particular cases, I still think my patch is better with the checks than not having them. I agree on something: It is boring to code this much for a small feature. But I would do it like this anyway. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #8 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Tomás Cohen Arazi from comment #7)
(In reply to Jonathan Druart from comment #2)
+ else { + Koha::Exceptions::WrongParameter->throw( + "'days' must be an integer" + ) unless looks_like_number($days); + $due_date->add( days => $days );
Developers will get an error anyway if $days is not an integer (DateTime will raise its own meaningful exception), or $hard_due_date is not a DateTime.
I tried removing the checks, and the results are not cool:
- Removing the check for DateTime object => found: Can't locate object method "clone" via package "cat" (perhaps you forgot to load "cat"?) at /kohadevbox/koha/Koha/Checkout.pm line 190.
Yes, that's the default perl error, everybody knows what it means :)
- Removing the check for number => found: normal exit, and a simple warning: Argument "dog" isn't numeric in addition (+) at /usr/lib/x86_64-linux-gnu/perl5/5.24/DateTime/Duration.pm line 74.
So, from the developer POV, in this particular cases, I still think my patch is better with the checks than not having them. I agree on something: It is boring to code this much for a small feature. But I would do it like this anyway.
There is a philosophic change we are making in these patches, and if you want to generalize them I think the discussion should be brought to the dev team. I guess there are hundreds of places where this check would be needed if such idea is adopted. What about splitting the patches in 2 parts, one for the move and the tests, another one moved to its own bug report for the data type check? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #9 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Forget that last comment and move on this. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |david@davidnind.com --- Comment #10 from David Nind <david@davidnind.com> --- Applying this patch seems to stop the 'Batch extend due dates' from working as expected (for me anyway): - Before applying the patch: issued some items, batch extend due dates comes up with items to extend the due date. - After applying the patch: Using exactly the same criteria the batch extend due dates shows 'No checkouts for the selected filters.' The tests still pass though! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |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=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #102273|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #11 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 110073 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110073&action=edit Bug 25039: Move new due date calculation to Koha::Checkout This is a follow-up patch of bug 25020. This patch adds a new method Koha::Checkout->shift_due_date that accepts the same parameters we provide in the form. It catches bad scenarios (type errors, passing both parameters when only one is accepted, and so on). Date manipulation is tested so time is kept and resulting dates are correct. The controller script is cleaned a bit to use the introduced method. I do this because: - We really need tests for this and doing it with selenium is no-end - I see a use for this new method for encapsulating behaviours, for example we might want to add Calendar support for the 'days' use case, and having the method here assures we will have tests, etc. To test: 1. Apply this patches 2. Repeat the original test plan => SUCCESS: Everything works as expected 3. Run: $ kshell k$ prove t/db_dependent/Koha/Checkout.t => SUCCESS: Tests pass! 4. 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=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #12 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Nind from comment #10)
Applying this patch seems to stop the 'Batch extend due dates' from working as expected (for me anyway):
- Before applying the patch: issued some items, batch extend due dates comes up with items to extend the due date.
- After applying the patch: Using exactly the same criteria the batch extend due dates shows 'No checkouts for the selected filters.'
Sorry for taking so long! That's correct, I used .count instead of .size, which would be the correct way of doing it as I changed into using an array. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #13 from David Nind <david@davidnind.com> --- Sorry Tomás, I can't seem to get this to work. - Before applying the patch the batch extend due date works as expected. - After applying the patch it no longer works: . check out some items, use batch extend due dates, set date in future . it looks like everything has worked - the preview and then the results list shows the new due dates . when looking at individual items, the due dates have not changed Hopefully it is something I'm doing wrong! The tests pass though... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #14 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 110460 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110460&action=edit Bug 25039: (follow-up) Don't forget to store the updated checkout 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=25039 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=25039 --- Comment #15 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Nind from comment #13)
Sorry Tomás, I can't seem to get this to work.
- Before applying the patch the batch extend due date works as expected.
- After applying the patch it no longer works: . check out some items, use batch extend due dates, set date in future . it looks like everything has worked - the preview and then the results list shows the new due dates . when looking at individual items, the due dates have not changed
Hopefully it is something I'm doing wrong!
Naw, it was just I forgot to commit the updated dates to the DB. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 David Nind <david@davidnind.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=25039 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110073|0 |1 is obsolete| | --- Comment #16 from David Nind <david@davidnind.com> --- Created attachment 110483 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110483&action=edit Bug 25039: Move new due date calculation to Koha::Checkout This is a follow-up patch of bug 25020. This patch adds a new method Koha::Checkout->shift_due_date that accepts the same parameters we provide in the form. It catches bad scenarios (type errors, passing both parameters when only one is accepted, and so on). Date manipulation is tested so time is kept and resulting dates are correct. The controller script is cleaned a bit to use the introduced method. I do this because: - We really need tests for this and doing it with selenium is no-end - I see a use for this new method for encapsulating behaviours, for example we might want to add Calendar support for the 'days' use case, and having the method here assures we will have tests, etc. To test: 1. Apply this patches 2. Repeat the original test plan => SUCCESS: Everything works as expected 3. Run: $ kshell k$ prove t/db_dependent/Koha/Checkout.t => SUCCESS: Tests pass! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110460|0 |1 is obsolete| | --- Comment #17 from David Nind <david@davidnind.com> --- Created attachment 110484 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110484&action=edit Bug 25039: (follow-up) Don't forget to store the updated checkout Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #18 from David Nind <david@davidnind.com> --- (In reply to Tomás Cohen Arazi from comment #15)
Naw, it was just I forgot to commit the updated dates to the DB.
It all works now and have signed off! One minor thing I noticed was that in the preview table listing changes to be made it shows the new due date as (for example) 09/21/2020 00:00 When applied the new due date is shown as 09/21/2020 23:59 on the item record and in the patron's circulation history. This may or may not be an issue... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #19 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to David Nind from comment #18)
(In reply to Tomás Cohen Arazi from comment #15)
Naw, it was just I forgot to commit the updated dates to the DB.
It all works now and have signed off!
One minor thing I noticed was that in the preview table listing changes to be made it shows the new due date as (for example) 09/21/2020 00:00
When applied the new due date is shown as 09/21/2020 23:59 on the item record and in the patron's circulation history.
This may or may not be an issue...
Hi David, I've added a new bug for this: Bug 26552 - Batch extend due date previews new due date as 00:00, but actually it's 23:59 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110483|0 |1 is obsolete| | --- Comment #20 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 110795 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110795&action=edit Bug 25039: Move new due date calculation to Koha::Checkout This is a follow-up patch of bug 25020. This patch adds a new method Koha::Checkout->shift_due_date that accepts the same parameters we provide in the form. It catches bad scenarios (type errors, passing both parameters when only one is accepted, and so on). Date manipulation is tested so time is kept and resulting dates are correct. The controller script is cleaned a bit to use the introduced method. I do this because: - We really need tests for this and doing it with selenium is no-end - I see a use for this new method for encapsulating behaviours, for example we might want to add Calendar support for the 'days' use case, and having the method here assures we will have tests, etc. To test: 1. Apply this patches 2. Repeat the original test plan => SUCCESS: Everything works as expected 3. Run: $ kshell k$ prove t/db_dependent/Koha/Checkout.t => SUCCESS: Tests pass! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.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=25039 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110484|0 |1 is obsolete| | --- Comment #21 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 110796 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110796&action=edit Bug 25039: (follow-up) Don't forget to store the updated checkout Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.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=25039 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #22 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Katrin Fischer from comment #19)
(In reply to David Nind from comment #18)
(In reply to Tomás Cohen Arazi from comment #15)
Naw, it was just I forgot to commit the updated dates to the DB.
It all works now and have signed off!
One minor thing I noticed was that in the preview table listing changes to be made it shows the new due date as (for example) 09/21/2020 00:00
When applied the new due date is shown as 09/21/2020 23:59 on the item record and in the patron's circulation history.
This may or may not be an issue...
Hi David, I've added a new bug for this:
Bug 26552 - Batch extend due date previews new due date as 00:00, but actually it's 23:59
This is the behaviour with this patch set, not master. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |26552 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26552 [Bug 26552] Batch extend due date previews new due date as 00:00, but actually it's 23:59 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #23 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #22)
(In reply to Katrin Fischer from comment #19)
(In reply to David Nind from comment #18)
(In reply to Tomás Cohen Arazi from comment #15)
Naw, it was just I forgot to commit the updated dates to the DB.
It all works now and have signed off!
One minor thing I noticed was that in the preview table listing changes to be made it shows the new due date as (for example) 09/21/2020 00:00
When applied the new due date is shown as 09/21/2020 23:59 on the item record and in the patron's circulation history.
This may or may not be an issue...
Hi David, I've added a new bug for this:
Bug 26552 - Batch extend due date previews new due date as 00:00, but actually it's 23:59
This is the behaviour with this patch set, not master.
Thx Joubu, sorry for missing the connection -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #24 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #22)
(In reply to Katrin Fischer from comment #19)
(In reply to David Nind from comment #18)
(In reply to Tomás Cohen Arazi from comment #15)
Naw, it was just I forgot to commit the updated dates to the DB.
It all works now and have signed off!
One minor thing I noticed was that in the preview table listing changes to be made it shows the new due date as (for example) 09/21/2020 00:00
When applied the new due date is shown as 09/21/2020 23:59 on the item record and in the patron's circulation history.
This may or may not be an issue...
Hi David, I've added a new bug for this:
Bug 26552 - Batch extend due date previews new due date as 00:00, but actually it's 23:59
This is the behaviour with this patch set, not master.
Are you sure? Date arithmetic is exactly the same. Isn't this highlighting some other bug? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #25 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 110905 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110905&action=edit Bug 25039: (QA follow-up) Restore date display The original implementation didn't display the time portion of the datetime object (00:00) as it used output_pref( ..., 'iso' ). This patch makes it do the same. 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=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 --- Comment #26 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- The current implementation displays the time part if needed: 140 <td>[% checkout.date_due | $KohaDates as_due_date => 1 %]</td> 147 [% new_due_dates.shift | $KohaDates as_due_date => 1 %] -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110905|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25039 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|tomascohen@gmail.com |koha-bugs@lists.koha-commun | |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org