The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog.
Created attachment 64383 [details] [review] Bug 18816 - Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Enable CataloguingLog 2) Note the checkins and checkouts cause log entries 3) Apply this patch 4) Note that checkins and checkouts no longer cause log entries, but editing the item will continue to cause log entries.
Created attachment 64393 [details] [review] Bug 18816 - Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Enable CataloguingLog 2) Note the checkins and checkouts cause log entries 3) Apply this patch 4) Note that checkins and checkouts no longer cause log entries, but editing the item will continue to cause log entries.
Patch does not apply because of bug 16354. :)
Patch does not apply because of bug 16534. :)
Created attachment 65711 [details] [review] Bug 18816 - Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Enable CataloguingLog 2) Note the checkins and checkouts cause log entries 3) Apply this patch 4) Note that checkins and checkouts no longer cause log entries, but editing the item will continue to cause log entries.
Created attachment 65712 [details] [review] Bug 18816 - Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Enable CataloguingLog 2) Note the checkins and checkouts cause log entries 3) Apply this patch 4) Note that checkins and checkouts no longer cause log entries, but editing the item will continue to cause log entries.
We applied the patch cleanly but the desired change in behavior did not happen. Tested with check in and check out. We were looking at the logs for the particular item.
Created attachment 68600 [details] [review] Bug 18816 - Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Enable CataloguingLog 2) Note the checkins and checkouts cause log entries 3) Apply this patch 4) Note that checkins and checkouts no longer cause log entries, but editing the item will continue to cause log entries.
(In reply to Lisette from comment #7) > We applied the patch cleanly but the desired change in behavior did not > happen. > Tested with check in and check out. > We were looking at the logs for the particular item. Fixed!
Created attachment 68647 [details] [review] Bug 18816 - Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Log into staff client 2) Home -> Koha administration -> Global system preferences -> Logs 3) Set only CataloguingLog to 'Log', everything else to "Don't log" 4) Click 'Save all Logging preferences' 5) In MySQL, use your instance DB, and then type 'delete from action_logs;' 6) Have a person checkout and checkin anything. 7) In MySQL, 'select * from action_logs;' -- there will be data. This is the floodiness that will be removed. 8) Apply this patch 9) Repeat steps 5-7 -- there should be no data. 10) Edit any biblio or item. 11) In MySQL, 'select * from action_logs;' -- there should be data reflecting the changes made. 12) run koha qa test tools NOTE: Improved clarity of test plan -- Mark Tompsett Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
This imo is an enhancement.
It might be useful to turn the last parameter of ModItem into a hashref of parameters. ModItem(\%item, $biblionumber, $itemnumber, {log_action => 0}); is more readable than ModItem(\%item, $biblionumber, $itemnumber, 0); What do you think ?
(In reply to Julian Maurice from comment #12) > It might be useful to turn the last parameter of ModItem into a hashref of > parameters. > > ModItem(\%item, $biblionumber, $itemnumber, {log_action => 0}); > > is more readable than > > ModItem(\%item, $biblionumber, $itemnumber, 0); > > What do you think ? I would agree.
+subtest 'Test logging for AddItem' => sub { You mean ModItem.
Created attachment 73154 [details] [review] Bug 18816: Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Log into staff client 2) Home -> Koha administration -> Global system preferences -> Logs 3) Set only CataloguingLog to 'Log', everything else to "Don't log" 4) Click 'Save all Logging preferences' 5) In MySQL, use your instance DB, and then type 'delete from action_logs;' 6) Have a person checkout and checkin anything. 7) In MySQL, 'select * from action_logs;' -- there will be data. This is the floodiness that will be removed. 8) Apply this patch 9) Repeat steps 5-7 -- there should be no data. 10) Edit any biblio or item. 11) In MySQL, 'select * from action_logs;' -- there should be data reflecting the changes made. 12) run koha qa test tools NOTE: Improved clarity of test plan -- Mark Tompsett Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Created attachment 73155 [details] [review] Bug 18816 [QA Followup]: Convert param to hashref, fix typo
We have a clash with parameters here: Look at "The fourth, optional parameter, C<$unlinked_item_subfields> "
Created attachment 73169 [details] [review] Bug 18816: Add rarely used params to hashref, remove param
Created attachment 73170 [details] [review] Bug 18816 [QA Followup]: Add rarely used params to hashref, remove param
Created attachment 73171 [details] [review] Bug 18816 [QA Followup]: Add rarely used params to hashref, remove param
QA: Looking here
Created attachment 73729 [details] [review] Bug 18816: Make CataloguingLog work in production by preventing circulation from spamming the log The system preference CataloguingLog is not recommended for use in production. This is do to the fact that every checkin and checkout generates one or more log entires. This seems to be not only bad behavior, but unnecessary and outside the needs of CataloguingLog as we have CirculationLog. Test Plan: 1) Log into staff client 2) Home -> Koha administration -> Global system preferences -> Logs 3) Set only CataloguingLog to 'Log', everything else to "Don't log" 4) Click 'Save all Logging preferences' 5) In MySQL, use your instance DB, and then type 'delete from action_logs;' 6) Have a person checkout and checkin anything. 7) In MySQL, 'select * from action_logs;' -- there will be data. This is the floodiness that will be removed. 8) Apply this patch 9) Repeat steps 5-7 -- there should be no data. 10) Edit any biblio or item. 11) In MySQL, 'select * from action_logs;' -- there should be data reflecting the changes made. 12) run koha qa test tools NOTE: Improved clarity of test plan -- Mark Tompsett Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 73730 [details] [review] Bug 18816 [QA Followup]: Convert param to hashref, fix typo Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 73731 [details] [review] Bug 18816 [QA Followup]: Add rarely used params to hashref, remove param Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 73732 [details] [review] Bug 18816: (QA follow-up) Framework parameter is not needed $frameworkcode is not used in ModItem (no need to pass it in ModItemFromMarc). $dbh is not used in ModItem. Test plan: Run t/db_dependent/Items.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 73733 [details] [review] Bug 18816: (QA follow-up) Fix Circulation.t Resolve: ok 33 - Can renew, item is marked not for loan, hold does not block Can't use string ("1") as a HASH ref while "strict refs" in use at /usr/share/koha/devclone/C4/Items.pm line 557. Trivial fix. Remove fourth parameter. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Pushed to master for 18.05, thanks to everybody involved!
Enhancement, not backported for 17.11.x
*** Bug 17195 has been marked as a duplicate of this bug. ***