Bug 10352 - Cataloguing log search mixing itemnumber/bibnumber
Summary: Cataloguing log search mixing itemnumber/bibnumber
Status: Signed Off
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: master
Hardware: All All
: P1 - high normal (vote)
Assignee: Jonathan Druart
QA Contact:
URL:
Keywords:
: 10680 14444 (view as bug list)
Depends on: 11473
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-27 13:10 UTC by Katrin Fischer
Modified: 2019-07-11 14:31 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 10352: Display the correct modification logs for bibliographic records (2.46 KB, patch)
2019-05-13 15:42 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 10352: Display the correct modification logs for bibliographic records (2.50 KB, patch)
2019-07-11 14:31 UTC, PTFS Europe Sandboxes
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2013-05-27 13:10:20 UTC
When testing the 'Modification log' tab on a given record with multiple items in my system I noticed that the search showed confusing results. 

Some things that seem not quite right:

The preselected search uses the biblionumber as object and 'all' for the log. This will bring up all changes for the record, but also all changes for any item which itemnumber matches the bibnumber.

If you limit the saerch to only show you the catalog log, you got the same problem.

There is no option to find all logs for all items of a given record. Also there is no way to find out if someone deleted items from a record as you don't know the missing itemnumbers.

And as object can be itemnumber or biblionumber the results can always be mixed up containing items and records with no relationship with each other.
Comment 1 Benjamin Daeuber 2016-10-05 21:42:37 UTC
I'd like to add to this that this is also patrons, not simply items and bibs. I think each one of these should be assigned a unique number, i.e. no item number should be assigned a number that already exists as a bib number or a patron number. I realize we can't fix existing records, but we can certainly ensure this doesn't happen going forward.
Comment 2 Jonathan Druart 2019-05-13 15:42:39 UTC
Created attachment 89668 [details] [review]
Bug 10352: Display the correct modification logs for bibliographic records

The 'Modification log" link in the cataloguing module returns confusing
results. The 'object' parameter is the biblionumber, but the all log
from itemnumber=biblionumber will be displayed as well.
Since bug 11473 we have the action_logs.info column that is prefixed by
'item ' or 'biblio ' to disociated an item modification from a biblio
modif.
This patch suggests a quick and dirty approach, use this column to make
sure we are searching for the correct logs.
/!\ As bug 11473 did not update the existing rows, we will no longer display
the logs created prior to this change.

Test plan:
Make sure you have at least 2 bibliographic records with some items
Make sure you have the biblionumbers of those records that match
existing itemnumbers
Edit them (no matter what you change)
Go to the bibliographic detail page (staff) and click "Modification log"
You should see the correct changes.
Comment 3 Liz Rea 2019-05-23 19:31:19 UTC
Jonathan,

would it be better to have an "old logs" mode, where things work the old way? People might need to access old logs after an upgrade and we'd be taking those away from them (unless I am misunderstandng what you've said here).

Liz
Comment 4 Jonathan Druart 2019-05-24 22:13:50 UTC
I was talking about "prior to bug 11473", so 3.16.x.

No access old logs vs access the wrong logs? :)
Comment 5 Liz Rea 2019-05-29 14:20:48 UTC
There are libraries outu there with history that long, though I"m not sure they'd ever have a reason to go back that far.

It's probably fine.
Comment 6 David Cook 2019-05-30 00:28:21 UTC
(In reply to Liz Rea from comment #5)
> There are libraries outu there with history that long, though I"m not sure
> they'd ever have a reason to go back that far.
> 
> It's probably fine.

The data will still be in the database, right? So I suppose worst case scenario they could do a SQL report? Although that's presuming they'd know that there has been a change to how the log viewer works...
Comment 7 Jonathan Druart 2019-05-30 02:40:25 UTC
*** Bug 10680 has been marked as a duplicate of this bug. ***
Comment 8 Jonathan Druart 2019-05-30 02:41:25 UTC
*** Bug 14444 has been marked as a duplicate of this bug. ***
Comment 9 PTFS Europe Sandboxes 2019-07-11 14:31:12 UTC
Created attachment 91466 [details] [review]
Bug 10352: Display the correct modification logs for bibliographic records

The 'Modification log" link in the cataloguing module returns confusing
results. The 'object' parameter is the biblionumber, but the all log
from itemnumber=biblionumber will be displayed as well.
Since bug 11473 we have the action_logs.info column that is prefixed by
'item ' or 'biblio ' to disociated an item modification from a biblio
modif.
This patch suggests a quick and dirty approach, use this column to make
sure we are searching for the correct logs.
/!\ As bug 11473 did not update the existing rows, we will no longer display
the logs created prior to this change.

Test plan:
Make sure you have at least 2 bibliographic records with some items
Make sure you have the biblionumbers of those records that match
existing itemnumbers
Edit them (no matter what you change)
Go to the bibliographic detail page (staff) and click "Modification log"
You should see the correct changes.

Signed-off-by: hc <hc@interleaf.ie>