https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19889
--- Comment #22 from Christopher Brannon <[email protected]> --- (In reply to Tomás Cohen Arazi from comment #21) > So the result is similar, but ugly-ish. And involves an error prone > free-text field with pipe-separated values. So I don't see any advantage on > it. If we were to expose this condition on the API also, we would need to > add methods to extract the boolean with this kind of comparison, instead of > just reading what's on the category table. What if it wasn't a free-text field? What if we did something similar to what is being done in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22844? Select the categories from a list rather than free typing? I'd prefer to keep these settings together, but if you think it makes more sense to put exclusions in the patron categories, then that would be acceptable. It works. My biggest concern is trying to debug behavior. It's one thing to have the items with their own exclusions in the record. But trying to figure out why it excluding items in some cases and not others because of a patron category exclusion might be more challenging. If there were some indicator when the exclusion is skipped somewhere, then I would have no problem with it. If it is logged, then it would be easy to trace. I'm just trying to make sure that our enhancement doesn't become a headache for those using it to try and understand system behavior. Circulation rules alone are hard to follow when dealing with multiple branches. -- 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/
