https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129
Victor Grousset/tuxayo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #44 from Victor Grousset/tuxayo <[email protected]> --- Bug 37054 looks like more grist to the mill of this. (In reply to Tomás Cohen Arazi (tcohen) from comment #11) > add a new > attribute to categories, and it will end-up being the same old pattern: > > - A syspref for a global/default value > - A per-category value So we have (among implemented or proposed features) per patron category: - like the above quote with Bug 27945 - Limit the number of active article requests per patron category - Bug 22457 - OpacHiddenItemsExceptions should be moved to a category attribute - Bug 29924 - Introduce password expiration to patron categories - Bug 18203 - Add per borrower category restrictions on placing ILL requests in OPAC Per library: - like for the earlier iteration of SMTP example - Bug 22343 - Add configuration options for SMTP servers - Bug 37054 - Allow for custom library colors in the staff interface And combination of these two or three (with item type) for things like - Bug 19889 - LocalHoldsPriority needs exclusions - various things in the circulation rules page That should be the known pile of example bugs relevant for here. +1 for storing new occurrences in the proposed configurations table. To avoid making wider other DB tables. To not set in stone that a config is dependent only on just library or patron category. If something needs more granularity, it will be easy to change on the storage side. To not multiply the associative tables for each config related to 2 or 3 of the usual core entities. To not mix presentation with business data. To make it easier when something linked to only to one of itype/cat/lib will need more granularity and thus to be linked to a pair. **Would a start that is not too big to chew be to implement the storage backend and use it for data associated with only one of the usual 3 core entities?** And have the UI still be in the page of the entity. So for what would have ended up an additional column of categories or libraries. It could be any of the proposed patches in the list above that could inaugurate using the configurations table. Without much dev overhead given the patches proposed here. For these cases the core entity config page might be the best place to have the UI anyway so it's only about the backend, separating the data and preparing the work for more complex cases. And making it easier for other simple cases. Like bug 37054 would have less trouble with already a good place to store the data. And then for something that needs a pair or triad of itype/cat/lib then a dedicated page/ui component is needed anyway. So that will be the moment to make the generic page/reusable component to manage these configs and facilitate implementing the subsequent cases of data associated with a pair/triad of the 3 usual core entities. But until then the data structure will be done and already providing benefits. And secondary data linked only to one of itype/cat/lib doesn't have anymore to require adding a column and having to mix with core business logic just because making the generic config page is too much work. Especially when these cases don't even benefit that much from it since it's only linked to one entity. Do Comment 5 has early implications for the storage backend or is not a worry for the 1st step? (and is not something that would tilt the scale against the whole concept) There is no need yet to settle on global configs also being there, right? -- 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/
