Bug 7403 - Remove warning from CataloguingLog system preference
Summary: Remove warning from CataloguingLog system preference
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: helene
QA Contact: Marcel de Rooy
URL:
Keywords: Academy
Depends on: 18816
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-05 14:22 UTC by Nicole C. Engard
Modified: 2019-02-04 09:54 UTC (History)
11 users (show)

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


Attachments
Bug 7403: Shorterned what the prefernce reads. To test: 1) Look at value of CataloguingLog prefernce 2) Apply the patch and the value should change 3) Verify that the warning has been removed (1.22 KB, patch)
2019-01-16 02:20 UTC, helene
Details | Diff | Splinter Review
Bug 7403: Shorten CataloguingLog preference description (1.28 KB, patch)
2019-01-16 21:19 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 7403: Shorten CataloguingLog preference description (1.38 KB, patch)
2019-01-25 10:56 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2012-01-05 14:22:04 UTC
The CataloguingLog preference says "Since this occurs whenever a book is checked in or out as well, it is not advisable to turn this on." but no one has ever been able to confirm that this is true. This warning should be removed unless someone can point to the code that makes this warning accurate.



From IRC:

[09:18]  <nengard> has anyone ever tested and confirmed the warning on the cataloguinglog preference? it says that its slows things down cause it tracks everytime the barcode is scanned - is that right? is the warning valid?
[09:19]  <jcamins> nengard: it is not correct.
[09:19]  <jcamins> nengard: at least, so far as I know.
[09:19]  <nengard> that's what i thought!!!
[09:19]  <nengard> and thank you jcamins
[09:19]  <nengard> i've asked this at least once a year for the last 4 years!
Comment 1 Nicole C. Engard 2012-01-05 14:47:53 UTC
Okay, the log does track all checkouts and ins, but the warning isn't exactly clear - we need to say that it's a size issue - and not a performance issue:




[09:29]  <sekjal> nengard:  I believe it's been incorrect since 3.4 was released, and items were removed from the biblio.
[09:29]  <tcohen> jcamins: AddIssue calls ModItem which happens to do some logging
[09:29]  <jcamins> nengard: I stand corrected.
[09:30]  <nengard> so it is incorrect now
[09:30]  <nengard> but wasn't before
[09:30]  <jcamins> tcohen: does it actually log anything? 3.6, it seems to me, is not logging issues in the cataloguing log.
[09:31]  <jwagner> jcamins, you forgot biblioitems from your truncate list.  Also need to check for any issues or reserves.
[09:32]  <tcohen> jcamins, i might be wrong, but I just checked that AddIssue calls ModItem
[09:32]  <tcohen> which happens to have :
[09:32]  <tcohen> logaction("CATALOGUING", "MODIFY", $itemnumber, Dumper($item)) if C4::Context->preference("CataloguingLog");
[09:32]  <tcohen> inside
[09:32]  <tcohen> i think it is not a problem any more, thou
[09:33]  <tcohen> because we don't do a ModBiblio, which was reallly expensive
[09:33]  <jcamins> jwagner: thanks.
[09:33]  <jcamins> nengard: the warning may still be correct, then.
[09:33]  <jcamins> nengard: I've never noticed any particular performance issues, though.
[09:33]  <tcohen> (because we log the whole marc there)
[09:39]  <nengard> yes, i just tested and when i checked an item out it added two lines to the cataloging log
[09:39]  <nengard> but does it actually slow things down?
[09:40]  <sekjal> nengard:  I don't think it's so much an issue of slowing down transactions, as storing TONS of data
[09:40]  <sekjal> so accessing the log table becomes slow
[09:40]  <sekjal> but I don't believe it would affect circ transactions or normal response time
[09:40]  <nengard> libraries might be okay with that - whereas they won't be okay with things slowing down checkouts and such
[09:40]  <tcohen> nengard, prior to removing items from marc/marcxml every time an item was borrowed
[09:41]  <tcohen> the biblio itself was modified
[09:41]  <tcohen> (the marc/marcxml stuff)
[09:41]  <tcohen> and the change was then logged
[09:41]  <nengard> it's nice to see that i just had to report a bug to get an answer to my question - like i said i've been asking about this for the manual for 4 years now
[09:41]  <tcohen> that was an expensive task, as the marc itself is saved in the log
Comment 2 Katrin Fischer 2013-04-13 21:24:53 UTC
The warning is still present on current master.
Comment 3 Katrin Fischer 2015-06-06 22:11:02 UTC
The warning is still present, also we somehow seem to add 2 entries for each checkout and return of an item.
Comment 4 Marc Véron 2016-01-26 17:08:20 UTC
(In reply to Katrin Fischer from comment #3)
> The warning is still present, also we somehow seem to add 2 entries for each
> checkout and return of an item.

Check out an item generates 2 entries:

2016-01-26 17:14:16 	A. Testman (51) 	Catalog 	Modify 	Item 364 	item $VAR1 = { 'itemnumber' => '364', 'issues' => 1, 'datelastborrowed' => '2016-01-26', 'holdingbranch' => 'CPL', 'itemlost_on' => undef, 'itemlost' => 0, 'onloan' => '2016-02-04' };

2016-01-26 17:14:16 	A. Testman (51) 	Catalog 	Modify 	Item 364 	item $VAR1 = { 'itemnumber' => '364', 'datelastseen' => '2016-01-26', 'itemlost_on' => undef, 'itemlost' => 0 }; 

Check in the item generates 3 entries, #1 and #2 are identical:

2016-01-26 17:16:21 	A. Testman (51) 	Catalog 	Modify 	Item 364 	item $VAR1 = { 'itemnumber' => '364', 'onloan' => undef };
2016-01-26 17:16:21 	A. Testman (51) 	Catalog 	Modify 	Item 364 	item $VAR1 = { 'itemnumber' => '364', 'onloan' => undef };
2016-01-26 17:16:21 	A. Testman (51) 	Catalog 	Modify 	Item 364 	item $VAR1 = { 'itemnumber' => '364', 'datelastseen' => '2016-01-26', 'itemlost_on' => undef, 'itemlost' => 0 }; 


It will be difficult to get that right, because while checking in and out, ModItem is called several times and generates each time a log entry (C4/Items.pm line 608)

Maybe the logs for items and for bibliographic records could be separated? E.g. use 'Cataloguing' for records only and a new log 'Items' for Items?
Comment 5 Katrin Fischer 2016-02-28 22:17:11 UTC
Separating the logs properly would make a lot of sense. But otherwise... calling it 3 times seems like overkill? Maybe hiding a bigger problem underneath.
Comment 6 Andrew Fuerste-Henry 2018-12-14 14:14:46 UTC
I believe this bug is newly relevant? Bug 18816 removed circ activity from the cataloging log, so the warning language should be removed.
Comment 7 Katrin Fischer 2019-01-02 22:36:28 UTC
The preference currently reads:

[Log|Don't log] any changes to bibliographic or item records. Since this occurs whenever a book is checked in or out as well, it is not advisable to turn this on. 


The second part "Since this occurs.." is no longer true with the changes from bug 18816 and can be removed.
Comment 8 helene 2019-01-16 02:20:45 UTC
Created attachment 84038 [details] [review]
Bug 7403: Shorterned what the prefernce reads. To test: 1) Look at value of CataloguingLog prefernce 2) Apply the patch and the value should change 3) Verify that the warning has been removed
Comment 9 Katrin Fischer 2019-01-16 21:19:51 UTC
Created attachment 84096 [details] [review]
Bug 7403: Shorten CataloguingLog preference description

To test:

1) Look at value of CataloguingLog prefernce
2) Apply the patch and the value should change
3) Verify that the warning has been removed

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 10 Marcel de Rooy 2019-01-25 10:56:31 UTC
Created attachment 84402 [details] [review]
Bug 7403: Shorten CataloguingLog preference description

To test:

1) Look at value of CataloguingLog prefernce
2) Apply the patch and the value should change
3) Verify that the warning has been removed

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 11 Nick Clemens 2019-01-25 17:57:17 UTC
Awesome work all!

Pushed to master for 19.05
Comment 12 Martin Renvoize 2019-01-31 16:35:59 UTC
Pushed to 18.11.x for 18.11.03
Comment 13 Lucas Gass 2019-02-01 20:43:12 UTC
pushed to 18.05.x for 18.05.09
Comment 14 Fridolin SOMERS 2019-02-04 09:54:22 UTC
Depends on Bug 18816 not in 17.11.x