https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42386
Martin Renvoize (ashimema) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #23 from Martin Renvoize (ashimema) <[email protected]> --- I like the direction of travel here.. but there's a fair few issues that need resolving and considering first. 1.Staff and OPAC hold-error templates were never updated for the snake_case rename — users now see generic/wrong messages instead of specific reasons. This patchset renames CanItemBeReserved/CanBookBeReserved status codes (e.g. ageRestricted → age_restricted) and updates every .pl caller, but reserve/request.tt and koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt are not in this diff at all and still switch on the old camelCase literals: - koha-tmpl/intranet-tmpl/prog/en/modules/reserve/request.tt:208-267 (two SWITCH/CASE blocks for failed_holds), :537 (IF (... || ageRestricted || ...)), :582 (biblioloo.tooManyHoldsForThisRecord), :976-998 (itemloo.not_holdable == 'ageRestricted' etc.), :1615-1616 (JS translation map keys). - koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt:83-105 (SWITCH fail / CASE 'ageRestricted' etc.) 2. You collapsed per-item hold-ability failures in the biblios hold check into a simpler no_item_available (no_items) response.. I agree this makes sense at the Biblio level given our past handling basically just returned the last item checked failure.. but I wonder if it might make sense to return both no_item_available and a 'reasons' array of itemnumber + failure code for future use? 3. Koha::Patron::Availability::Hold->check lost branch/itemtype filtering on the reservesallowed count, silently breaking per-branch/per-itemtype hold limits. We've had loads of bugs around this over the years.. we can't afford to lose the branch/itemtype level policy resolution 4. Your DBIC changes are inlined in another patch.. they should be split out to make sure the RM doesn't loose your other changes when regenerating 5. REST API error message format is a silent breaking change for third-party consumers. I like this change, but could we perhaps include an error code as well as the stringified error.. it looks like we're missing that here. -- 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/
