[Bug 32563] New: Reservedate becomes expirationdate in some cases
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Bug ID: 32563 Summary: Reservedate becomes expirationdate in some cases Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: slavashishkin@gmail.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Database fields DATE/DATETIME/TIMESTAMP in DBIX-Class are automatically available as DateTime objects that we can perform operations on (for example add an interval). But there is a feature: addition or subtraction operations (->add in this case) change the main object in-place and return the new value as the result of the expression. Because of this feature, due to the fact that the address to ->reserve date was passed to the ->add function, ->reservedate itself was changed, and then the result was assigned to ->expirationdate. This implicit feature resulted in an error when both dates after the given operation were the same in the future. Solution: To not change the original DateTime object, it must be cloned: https://metacpan.org/pod/DateTime#$dt-%3Eclone , accordingly, the changes will be made in a temporary copy, and a new value will be assigned to expirationdate, and the original reservedate will not change. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Slava Shishkin <slavashishkin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 --- Comment #1 from Slava Shishkin <slavashishkin@gmail.com> --- Created attachment 145003 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145003&action=edit Bug 32563: HOTFIX: reservedate becomes expirationdate in some cases To reproduce: 1. Go to /cgi-bin/koha/admin/preferences.pl?op=search&searchfield=DefaultHoldExpirationdate 2. Setup default expiration date to be 1 year from reserve date for example. 3. Switch to catalog to any biblio with item for example /cgi-bin/koha/catalogue/detail.pl?biblionumber=1 and place a hold for any borrower. 4. Check holds for this item, as by example /cgi-bin/koha/reserve/request.pl?biblionumber=1 5. Observe the field "Date" contains the same date as the "Expiration" which is wrong and both contains date 1 year in the future. "Date" should have a date the reservation made, i.e. now. 6. Apply the patch. 7. Make another hold, i.e. repeat steps 3-5 8. Observe the field "Date" contains correct date (today) but the "Expiration" date is 1 year in the future as set is step 2. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Andrew Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |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=32563 Biblibre Sandboxes <sandboxes@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #145003|0 |1 is obsolete| | --- Comment #2 from Biblibre Sandboxes <sandboxes@biblibre.com> --- Created attachment 145573 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145573&action=edit Bug 32563: HOTFIX: reservedate becomes expirationdate in some cases To reproduce: 1. Go to /cgi-bin/koha/admin/preferences.pl?op=search&searchfield=DefaultHoldExpirationdate 2. Setup default expiration date to be 1 year from reserve date for example. 3. Switch to catalog to any biblio with item for example /cgi-bin/koha/catalogue/detail.pl?biblionumber=1 and place a hold for any borrower. 4. Check holds for this item, as by example /cgi-bin/koha/reserve/request.pl?biblionumber=1 5. Observe the field "Date" contains the same date as the "Expiration" which is wrong and both contains date 1 year in the future. "Date" should have a date the reservation made, i.e. now. 6. Apply the patch. 7. Make another hold, i.e. repeat steps 3-5 8. Observe the field "Date" contains correct date (today) but the "Expiration" date is 1 year in the future as set is step 2. Signed-off-by: Amaury GAU <amaury.gau@bulac.fr> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Amaury GAU <amaury.gau@bulac.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |amaury.gau@bulac.fr -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Anneli Österman <anneli.osterman@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply CC| |anneli.osterman@koha-suomi. | |fi --- Comment #3 from Anneli Österman <anneli.osterman@koha-suomi.fi> --- I tested this in PTFS-Europe's sandbox and noticed that if DefaultHoldExpirationdate is set and I trap a hold and revert the hold's waiting status and then try to cancel the hold, I get an error. {UNKNOWN}: Can't locate object method "clone" via package "2023-01-27" (perhaps you forgot to load "2023-01-27"?) at /kohadevbox/koha/Koha/Hold.pm line 898. at /kohadevbox/koha/Koha/Hold.pm line 762 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 The hold's expirationdate should have been set back to the original expirationdate but it becomes empty. When I check reserves table the hold does not have expirationdate or patron_expiration_date set. If DefaultHoldExpirationdate is not set cancelling the hold works fine after these same steps. To reproduce: 1. Go to /cgi-bin/koha/admin/preferences.pl?op=search&searchfield=DefaultHoldExpirationdate 2. Setup default expiration date to be 1 year from reserve date for example. 3. Switch to catalog to any biblio with item for example /cgi-bin/koha/catalogue/detail.pl?biblionumber=1 and place a hold for any borrower. 4. Check in an item from the biblio you reserved and your hold gets trapped. 5. Go to the biblio and to it's holds page and revert the waiting status of your hold. 6. Notice that expiration date is empty. 7. Cancel the hold and get an error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emmi.takkinen@koha-suomi.fi --- Comment #4 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Anneli Österman from comment #3)
I tested this in PTFS-Europe's sandbox and noticed that if DefaultHoldExpirationdate is set and I trap a hold and revert the hold's waiting status and then try to cancel the hold, I get an error.
{UNKNOWN}: Can't locate object method "clone" via package "2023-01-27" (perhaps you forgot to load "2023-01-27"?) at /kohadevbox/koha/Koha/Hold.pm line 898. at /kohadevbox/koha/Koha/Hold.pm line 762 at /usr/share/perl5/DBIx/Class/Exception.pm line 77
The hold's expirationdate should have been set back to the original expirationdate but it becomes empty. When I check reserves table the hold does not have expirationdate or patron_expiration_date set.
This happens because reservedate fetched from database is not a DateTime object. Instead cloning $self->reservedate we should use dt_from_string to $self->reservedate and then clone. Then use that clone with add. Something like this:
my $reservedate = dt_from_string( $self->reservedate ); my $reservedate_clone = $reservedate->clone; $self->expirationdate( $reservedate_clone->add( $timeunit => $period ) );
-- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 --- Comment #5 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- Created attachment 149857 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149857&action=edit Bug 32563: Cloning $self->reservedate leads to error 500 If DefaultHoldExpirationdate is set and I trap a hold and revert the hold's waiting status and then try to cancel the hold, I get an error. To test: 1. Go to /cgi-bin/koha/admin/preferences.pl?op=search&searchfield=DefaultHoldExpirationdate 2. Setup default expiration date to be 1 year from reserve date for example. 3. Switch to catalog to any biblio with item for example /cgi-bin/koha/catalogue/detail.pl?biblionumber=1 and place a hold for any borrower. 4. Check in an item from the biblio you reserved and your hold gets trapped. 5. Go to the biblio and to it's holds page and revert the waiting status of your hold. 6. Notice that expiration date is empty. 7. Cancel the hold and get an error. 8. Apply this patch. 9. Repeat step above, but now no error should be raised. Also prove prove t/db_dependent/Hold.t Sponsored-by: Koha-Suomi Oy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |RESOLVED CC| |nick@bywatersolutions.com Resolution|--- |DUPLICATE --- Comment #6 from Nick Clemens <nick@bywatersolutions.com> --- *** This bug has been marked as a duplicate of bug 33611 *** -- 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