Bug 28799

Summary: Action logs should capture lost items found
Product: Koha Reporter: hebah
Component: Transaction logsAssignee: Nick Clemens <nick>
Status: CLOSED FIXED QA Contact: Katrin Fischer <katrin.fischer>
Severity: normal    
Priority: P5 - low CC: andrewfh, jonathan.druart, lucas, nick
Version: Main   
Hardware: All   
OS: All   
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
Bug 28799: Log when item was lost and now found
Bug 28799: Log when item was lost and now found
Bug 28799: Log when item was lost and now found
Bug 28799: Log when item was lost and now found

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