https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23010
Emily Lamancusa (emlam) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #36 from Emily Lamancusa (emlam) <[email protected]> --- Thanks for working on this one, Lucas! I found a few things that need follow-up, but it's pretty close! If you're able to follow up before the deadline for this cycle, I'll do my best to review it right away and move it along. == Blockers == - Test coverage needed for the changes to BatchItemUpdate.pm and Items.pm in the last patch - The Automatic Item Modification by Age tool is able to set the withdrawn status, so it needs to handle the exception. Currently, with the patchset, the cron crashes if it tries to set the withdrawn status on an item where withdrawing is not allowed. Example steps to produce the error: 1. Set PreventWithdrawingItemsStatus to prevent withdrawing on both checkout and in-transit 2. Add the following Automatic Item Modification by Age rule: age: 365 age field: items.dateaccessioned condition: items.biblionumber = 126 substitution: items.withdrawn = 1 **Note, due to bug 39864, you currently cannot do this through the staff interface, and you need to insert the rule directly into the database: INSERT INTO systempreferences(variable, value) VALUES ('automatic_item_modification_by_age_configuration', '[{"agefield":"items.dateaccessioned","conditions":[{"value":126,"field":"items.biblionumber"}],"age":"400","substitutions":[{"field":"items.withdrawn","value":"1"}]}]'); 3. Search for biblionumber 126 (Intermediate Perl) 4. Check out one of its items and put another one of its items in-transit 5. misc/cronjobs/automatic_item_modification_by_age.pl -v --> Confirm the cron will try to withdraw the 4 items from that bib 6. misc/cronjobs/automatic_item_modification_by_age.pl -c --> Cron job throws an exception (When I tested the above, one of the items that should have been withdrawn did not get withdrawn because the cron crashed, but I'm not sure what determines the order in which the items are processed, so ymmv) == Needs feedback == From additem.pl (around line 650): + } catch { + if ( ref $_ && $_->can('error') ) { + push @errors, $_->error; + } + } Should we do something else with the error (or die/rethrow) if not $_->can('error')? I imagine it would be a pretty unusual edge case for that check to fail, but if it does, we shouldn't fail silently. ---- From cataloguing_additem.js: $(document).ready(function () { + $( + '#cataloguing_additem_newitem #f[action^="/cgi-bin/koha/cataloguing/additem.pl"]' + ); // Remove the onclick event defined in browser.js, // otherwise the deletion confirmation will not work correctly $('a[href*="biblionumber="]').off("click"); It's not clear to me what this change does or if it's intentional. If it is an intentional change, can you clarify? -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
