Bug 10352

Summary: Cataloguing log search mixing itemnumber/bibnumber
Product: Koha Reporter: Katrin Fischer <katrin.fischer>
Component: ToolsAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Marcel de Rooy <m.de.rooy>
Severity: normal    
Priority: P1 - high CC: 1joynelson, bdaeuber, black23, dcook, hayleypelham, hc, jonathan.druart, kelly, kyle, lucas, m.de.rooy, mtj, nick, severine.queune, wizzyrea
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10680
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14444
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12235
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
20.05.00, 19.11.03, 19.05.08
Bug Depends on: 11473    
Bug Blocks:    
Attachments: Bug 10352: Display the correct modification logs for bibliographic records
Bug 10352: Display the correct modification logs for bibliographic records
Bug 10352: Use a new object_type parameter instead of the module's name
Bug 10352: Display the correct modification logs for bibliographic records
Bug 10352: Use a new object_type parameter instead of the module's name
Bug 10352: (follow-up) show the biblionumber for items in modification logs
Bug 10352: (follow-up) show the biblionumber for items in modification logs
Bug 10352: Get add operations too
Bug 10352: Get add operations too
Bug 10352: Display the correct modification logs for bibliographic records
Bug 10352: Use a new object_type parameter instead of the module's name
Bug 10352: (follow-up) show the biblionumber for items in modification logs
Bug 10352: Get add operations too

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>
Comment 10 Nick Clemens 2019-07-19 09:58:02 UTC
This does what is advertised, however, I can no longer view the Cataloging log for items now? I can see them if I click all, but not if I only want cataloging changes for items
Comment 11 Jonathan Druart 2019-08-05 17:23:44 UTC
(In reply to Nick Clemens from comment #10)
> This does what is advertised, however, I can no longer view the Cataloging
> log for items now? I can see them if I click all, but not if I only want
> cataloging changes for items

I do not understand what you mean.

- Edit an item
- Go to the detail page of the bib record
- Click "Modification log"
- I see the change for the item at the bottom of the page
Comment 12 Nick Clemens 2019-08-07 17:43:30 UTC
(In reply to Jonathan Druart from comment #11)
> (In reply to Nick Clemens from comment #10)
> I do not understand what you mean.


Sorry, what I meant is that you cannot directly search the catalog logs for an itemnumber - you must now enter the biblionumber

 - Have an itemnumber that is a biblionumber and one that isn't
 - Browse to Tools -> Log viewer
 - Enter the itemnumber in the 'Object' field, select 'Catalog' module
 - Submit
   - If the itemnumber is a biblio you get the mod log for the biblio (which may not contain your item)
   - If the itemnumber is not a biblio you get 'No log found...'

We fix the links, but not general searching. Possibly a radio button to choose item/biblionumber if searching catalog? I don't really like that there is magic happening for a cataloging log search
Comment 13 Jonathan Druart 2019-11-25 10:29:54 UTC
Created attachment 95776 [details] [review]
Bug 10352: Use a new object_type parameter instead of the module's name

To dissociate a search on biblio and item, we pass a new "object_type"
parameter to viewlog.pl. If equals 'biblio' we will assume that "object"
contains a biblionumber
Comment 14 Jonathan Druart 2019-11-25 10:31:11 UTC
(In reply to Nick Clemens from comment #12)
> (In reply to Jonathan Druart from comment #11)
> > (In reply to Nick Clemens from comment #10)
> > I do not understand what you mean.
> 
> 
> Sorry, what I meant is that you cannot directly search the catalog logs for
> an itemnumber - you must now enter the biblionumber
> 
>  - Have an itemnumber that is a biblionumber and one that isn't
>  - Browse to Tools -> Log viewer
>  - Enter the itemnumber in the 'Object' field, select 'Catalog' module
>  - Submit
>    - If the itemnumber is a biblio you get the mod log for the biblio (which
> may not contain your item)
>    - If the itemnumber is not a biblio you get 'No log found...'
> 
> We fix the links, but not general searching. Possibly a radio button to
> choose item/biblionumber if searching catalog? I don't really like that
> there is magic happening for a cataloging log search

Thanks for the suggestion but I would prefer to avoid adding a new box on the form and play with JS code.
I picked the lazy approach, but will fix your concern.
Comment 15 Nick Clemens 2019-11-25 12:17:53 UTC
Created attachment 95783 [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>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 16 Nick Clemens 2019-11-25 12:17:56 UTC
Created attachment 95784 [details] [review]
Bug 10352: Use a new object_type parameter instead of the module's name

To dissociate a search on biblio and item, we pass a new "object_type"
parameter to viewlog.pl. If equals 'biblio' we will assume that "object"
contains a biblionumber

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 17 Nick Clemens 2019-11-25 12:18:00 UTC
Created attachment 95785 [details] [review]
Bug 10352: (follow-up) show the biblionumber for items in modification logs

This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious

To test:
1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber
   i.e. In the sample data:
        biblionumber 59 with item with itemnumber 127
        item with itemnumber  59 on biblionumber 23
2 - Edit both items however you wish
3 - On biblionumber 59 click the modification log
4 - You should see "Item 127"
5 - Click "Submit" on the form - this searches as itemnumber
6 - You should see "Item 59"
7 - Apply patch
8 - On biblionumber 59 click the modification log
9 - You should see "Item 127 from Biblio 59"
10 - Click "Submit" on the form - this searches as itemnumber
11 - You should see "Item 59 from Biblio 23"
Comment 18 Jonathan Druart 2019-11-25 12:24:01 UTC
Created attachment 95786 [details] [review]
Bug 10352: (follow-up) show the biblionumber for items in modification logs

This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious

To test:
1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber
   i.e. In the sample data:
        biblionumber 59 with item with itemnumber 127
        item with itemnumber  59 on biblionumber 23
2 - Edit both items however you wish
3 - On biblionumber 59 click the modification log
4 - You should see "Item 127"
5 - Click "Submit" on the form - this searches as itemnumber
6 - You should see "Item 59"
7 - Apply patch
8 - On biblionumber 59 click the modification log
9 - You should see "Item 127 from Biblio 59"
10 - Click "Submit" on the form - this searches as itemnumber
11 - You should see "Item 59 from Biblio 23"

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 19 Kelly McElligott 2019-11-26 13:33:37 UTC
I have gone through the test plan, and I would like to understand step 10 a bit more.  From the user's perspective, go to the modification log from one bib (bib 59) and see you are getting bib# x and Item #y, but then hitting Submit (never leaving the log page) will retrieve results will get a different "object".   No other parameters changed in the system log filter such as Module, Object, Action.  How would the user understand the difference?  There is a lot of logic that is happening behind the scenes that the user doesn't know.
Comment 20 Jonathan Druart 2019-11-29 11:26:35 UTC
I agree with you Kelly. I would suggest to move forward with those patches, to fix the long standing issue, then deal with an ergonomic improvement on a separate bug report.
Comment 21 Marcel de Rooy 2019-12-13 10:37:05 UTC
Missing this one now:

12/06/2019 10:54 	Marcel Dev (51) 	Catalog 	Add 	Biblio 474 	biblio 	intranet 

Getting only item changes.

I am not sure if I really understand "deal with ergonomic somewhere else" argument.
What we do now, is: Toggle item / biblio. While we want both.

I think we should adjust the query on this report. Does not seem to be a large change.
Comment 22 Jonathan Druart 2019-12-13 10:59:43 UTC
(In reply to Marcel de Rooy from comment #21)
> I think we should adjust the query on this report. Does not seem to be a
> large change.

If you are volunteering I am all good with doing it here :)
Comment 23 Marcel de Rooy 2019-12-13 11:05:29 UTC
(In reply to Jonathan Druart from comment #22)
> (In reply to Marcel de Rooy from comment #21)
> > I think we should adjust the query on this report. Does not seem to be a
> > large change.
> 
> If you are volunteering I am all good with doing it here :)

QA / conflict of interests ;)
Comment 24 Nick Clemens 2019-12-13 17:10:10 UTC
Created attachment 96273 [details] [review]
Bug 10352: Get add operations too

When an add for biblio or item is recorded there is no space in the info field
Comment 25 Nick Clemens 2019-12-13 17:11:37 UTC
This does alleviate the specific missing line that Marcel highlighted, it did point out to me though that item deletions are not going to be picked up here - we need Koha::Old::Items to get the deleted numbers to check the logs.

I think this one has pointed out we have more work to do, but doe offer improvement
Comment 26 Jonathan Druart 2019-12-16 13:47:23 UTC
Created attachment 96336 [details] [review]
Bug 10352: Get add operations too

When an add for biblio or item is recorded there is no space in the info field

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 27 Katrin Fischer 2020-01-05 14:10:16 UTC
*** Bug 12235 has been marked as a duplicate of this bug. ***
Comment 28 Marcel de Rooy 2020-01-10 07:39:27 UTC
Created attachment 97147 [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>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 29 Marcel de Rooy 2020-01-10 07:39:32 UTC
Created attachment 97148 [details] [review]
Bug 10352: Use a new object_type parameter instead of the module's name

To dissociate a search on biblio and item, we pass a new "object_type"
parameter to viewlog.pl. If equals 'biblio' we will assume that "object"
contains a biblionumber

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 30 Marcel de Rooy 2020-01-10 07:39:37 UTC
Created attachment 97149 [details] [review]
Bug 10352: (follow-up) show the biblionumber for items in modification logs

This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious

To test:
1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber
   i.e. In the sample data:
        biblionumber 59 with item with itemnumber 127
        item with itemnumber  59 on biblionumber 23
2 - Edit both items however you wish
3 - On biblionumber 59 click the modification log
4 - You should see "Item 127"
5 - Click "Submit" on the form - this searches as itemnumber
6 - You should see "Item 59"
7 - Apply patch
8 - On biblionumber 59 click the modification log
9 - You should see "Item 127 from Biblio 59"
10 - Click "Submit" on the form - this searches as itemnumber
11 - You should see "Item 59 from Biblio 23"

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 31 Marcel de Rooy 2020-01-10 07:39:42 UTC
Created attachment 97150 [details] [review]
Bug 10352: Get add operations too

When an add for biblio or item is recorded there is no space in the info field

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 32 Martin Renvoize 2020-01-10 08:38:56 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 33 Joy Nelson 2020-01-30 23:36:08 UTC
Pushed to 19.11.x branch for 19.11.03
Comment 34 Lucas Gass 2020-02-05 21:51:54 UTC
backported to 19.05.x for 19.05.08
Comment 35 Hayley Pelham 2020-02-10 00:23:08 UTC
Enhancement will not be backported to 18.11.x series.