Bug 28799 - Action logs should capture lost items found
Summary: Action logs should capture lost items found
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Transaction logs (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Nick Clemens
QA Contact: Katrin Fischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-02 17:07 UTC by hebah
Modified: 2023-12-28 20:42 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
22.11.00


Attachments
Bug 28799: Log when item was lost and now found (1.47 KB, patch)
2021-08-05 13:22 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 28799: Log when item was lost and now found (1.52 KB, patch)
2021-08-05 19:42 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 28799: Log when item was lost and now found (3.99 KB, patch)
2022-09-21 19:18 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 28799: Log when item was lost and now found (4.05 KB, patch)
2022-09-22 13:52 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 28799: Log when item was lost and now found (4.10 KB, patch)
2022-10-08 10:50 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description hebah 2021-08-02 17:07:30 UTC
*Mark item lost
*Check action log for item to show lost status change
*Check item back in
*Action log doesn't update with lost status change
Comment 1 Jonathan Druart 2021-08-03 09:46:09 UTC
In master there is no action log when the item is checked in.

On which version did you test?
Comment 2 hebah 2021-08-03 14:01:29 UTC
(In reply to Jonathan Druart from comment #1)
> In master there is no action log when the item is checked in.
> 
> On which version did you test?

20.05. I've updated ticket to reflect that.
Comment 3 Jonathan Druart 2021-08-04 06:39:03 UTC
Should we remove the log then? Is the behaviour in master correct?
Comment 4 Nick Clemens 2021-08-05 13:22:52 UTC
Created attachment 123480 [details] [review]
Bug 28799: Log when item was lost and now found

In the subroutine ModDateLastSeen we unset an item's lost status when checked in.

This routine passes a noi log parameter to the store request, this is to avoid spamming the cataloguing log on every checkin.

When marking an item unlost we should record this change.

To test:
1 - Enable cataloguing log
2 - Mark an item lost
3 - View the log and confirm this chagne was recorded
4 - Check the item in
5 - The message indicates item is now found, but logs have no new entry
6 - Apply patch, restart all
7 - Mark the item lost and verify it is logged
8 - Check the item in, reported found and log entry recorded
Comment 5 Owen Leonard 2021-08-05 19:42:01 UTC
Created attachment 123530 [details] [review]
Bug 28799: Log when item was lost and now found

In the subroutine ModDateLastSeen we unset an item's lost status when
checked in.

This routine passes a noi log parameter to the store request, this is
to avoid spamming the cataloguing log on every checkin.

When marking an item unlost we should record this change.

To test:
1 - Enable cataloguing log
2 - Mark an item lost
3 - View the log and confirm this chagne was recorded
4 - Check the item in
5 - The message indicates item is now found, but logs have no new entry
6 - Apply patch, restart all
7 - Mark the item lost and verify it is logged
8 - Check the item in, reported found and log entry recorded

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 6 Jonathan Druart 2021-08-06 09:04:22 UTC
I think you should take leave_item_lost into account.

Also we need tests to cover the changes.

Additional question, do we really want a cataloguing log when an item is modified outside of the cataloguing module?
Comment 7 Katrin Fischer 2021-08-07 00:21:55 UTC
(In reply to Jonathan Druart from comment #6)
> I think you should take leave_item_lost into account.
> 
> Also we need tests to cover the changes.
> 
> Additional question, do we really want a cataloguing log when an item is
> modified outside of the cataloguing module?

I think yes, if you decide to log changes to something, it should not matter where it is changed, you want to know when it changed and who did it.
Comment 8 Nick Clemens 2022-09-21 19:18:10 UTC
Created attachment 140831 [details] [review]
Bug 28799: Log when item was lost and now found

In the subroutine ModDateLastSeen we unset an item's lost status when
checked in.

This routine passes a noi log parameter to the store request, this is
to avoid spamming the cataloguing log on every checkin.

When marking an item unlost we should record this change.

To test:
1 - Enable cataloguing log
2 - Mark an item lost
3 - View the log and confirm this chagne was recorded
4 - Check the item in
5 - The message indicates item is now found, but logs have no new entry
6 - Apply patch, restart all
7 - Mark the item lost and verify it is logged
8 - Check the item in, reported found and log entry recorded
Comment 9 Biblibre Sandboxes 2022-09-22 13:52:30 UTC
Created attachment 140849 [details] [review]
Bug 28799: Log when item was lost and now found

In the subroutine ModDateLastSeen we unset an item's lost status when
checked in.

This routine passes a noi log parameter to the store request, this is
to avoid spamming the cataloguing log on every checkin.

When marking an item unlost we should record this change.

To test:
1 - Enable cataloguing log
2 - Mark an item lost
3 - View the log and confirm this chagne was recorded
4 - Check the item in
5 - The message indicates item is now found, but logs have no new entry
6 - Apply patch, restart all
7 - Mark the item lost and verify it is logged
8 - Check the item in, reported found and log entry recorded

Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Comment 10 Katrin Fischer 2022-10-08 10:50:22 UTC
Created attachment 141542 [details] [review]
Bug 28799: Log when item was lost and now found

In the subroutine ModDateLastSeen we unset an item's lost status when
checked in.

This routine passes a noi log parameter to the store request, this is
to avoid spamming the cataloguing log on every checkin.

When marking an item unlost we should record this change.

To test:
1 - Enable cataloguing log
2 - Mark an item lost
3 - View the log and confirm this chagne was recorded
4 - Check the item in
5 - The message indicates item is now found, but logs have no new entry
6 - Apply patch, restart all
7 - Mark the item lost and verify it is logged
8 - Check the item in, reported found and log entry recorded

Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 11 Tomás Cohen Arazi 2022-10-11 14:21:05 UTC
Pushed to master for 22.11.

Nice work everyone, thanks!
Comment 12 Lucas Gass 2022-12-05 18:26:01 UTC
Doesn't apply cleanly to 22.05.x, no backport