Bug 27921 - Timestamp in holds log is out of date when a hold is marked as waiting
Summary: Timestamp in holds log is out of date when a hold is marked as waiting
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-10 20:07 UTC by Nick Clemens
Modified: 2021-04-24 17:12 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Text to go in the release notes:
Version(s) released in:
21.05.00,20.11.05,20.05.11


Attachments
Bug 27921: Log correct timestamp for HOLD MODIFY when set waiting (3.51 KB, patch)
2021-03-11 15:14 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 27921: Log correct timestamp for HOLD MODIFY when set waiting (3.56 KB, patch)
2021-03-16 12:49 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 27921: Log correct timestamp for HOLD MODIFY when set waiting (3.62 KB, patch)
2021-03-25 14:36 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2021-03-10 20:07:00 UTC
The code calls 'set_waiting' which sets some values in the object and calls store. The store updates the timestamp of the hold in the db, but the hold object is not refreshed before logging, so the timestamp does not get updated
Comment 1 Jonathan Druart 2021-03-11 15:14:08 UTC
Created attachment 118147 [details] [review]
Bug 27921: Log correct timestamp for HOLD MODIFY when set waiting

The HOLD MODIFY log at the end of ModReserveAffect is not using an
up-to-date $hold object.

$hold is modified at
1201         $hold->set_waiting($desk_id);
But not refreshed before logged (and so the timestamp is not logged
correctly).

Test plan:
Turn on HoldsLog
Place an item on hold
Check it in to mark it waiting

Confirm that the timestamp logged is the one from the check in, not when
you created the hold
Comment 2 Owen Leonard 2021-03-16 12:49:16 UTC
Created attachment 118314 [details] [review]
Bug 27921: Log correct timestamp for HOLD MODIFY when set waiting

The HOLD MODIFY log at the end of ModReserveAffect is not using an
up-to-date $hold object.

$hold is modified at
1201         $hold->set_waiting($desk_id);
But not refreshed before logged (and so the timestamp is not logged
correctly).

Test plan:
Turn on HoldsLog
Place an item on hold
Check it in to mark it waiting

Confirm that the timestamp logged is the one from the check in, not when
you created the hold

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 3 Martin Renvoize 2021-03-25 14:36:42 UTC
Created attachment 118813 [details] [review]
Bug 27921: Log correct timestamp for HOLD MODIFY when set waiting

The HOLD MODIFY log at the end of ModReserveAffect is not using an
up-to-date $hold object.

$hold is modified at
1201         $hold->set_waiting($desk_id);
But not refreshed before logged (and so the timestamp is not logged
correctly).

Test plan:
Turn on HoldsLog
Place an item on hold
Check it in to mark it waiting

Confirm that the timestamp logged is the one from the check in, not when
you created the hold

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 4 Martin Renvoize 2021-03-25 14:37:05 UTC
Good catch, Passing QA
Comment 5 Jonathan Druart 2021-04-01 16:54:35 UTC
Pushed to master for 21.05, thanks to everybody involved!
Comment 6 Fridolin Somers 2021-04-13 15:08:21 UTC
Pushed to 20.11.x for 20.11.05
Comment 7 Andrew Fuerste-Henry 2021-04-24 16:03:02 UTC
Pushed to 20.05.x for 20.05.11
Comment 8 Victor Grousset/tuxayo 2021-04-24 17:12:11 UTC
Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed.