I concur with Julian observations. A configuration selection per
library-item_type-category will be too much or not enough depending on the
context. We will end up with another table containing zillions of records for
trivial things. Tomas, have you considered a hierarchical configuration data
structure like the one found in Sublime text editor (I recall you're a Sublime
user...) ? We currently also have all those "YAML" configurations that are
stored in files (OAI, ElasticSeach) or in system preferences that won't fit in
a new library-type-category configuration table. The XML configuration files
fall into the same category of data structure.
Another onservation. You express this need:
the ability to set values with per-library, per-item type and per-category
basis, as well as default catch-all
We have this need (this 'pattern' as you said) potentially everywhere in Koha.
But we also need (1) more, and (2) a clear understanding of how the
'catch-all' or the 'fall-back' works.
(1) We need more (eventually). For example, you may need to combine the item
type with the ccode, item homebranch, and borrowr branch, in order to select
a claim letter. This could be something like this:
item.homebranch ne 'MAIN' && item.ccode eq 'EBOOK' &&
borrower.country ne 'Monaco' && borrower.branchcode eq 'SCIENCE'
(2) We need to understand how the various criteria are evaluated and in which
order. Sequential order seems reasonable. With this, having an issue, you
evaluate 3 criteria in order to select a value:
[
{
"criteria": "item.homebranch eq 'MAIN' && borrower.category eq 'ADULT'",
"value": "abcd"
},
{
"criteria": "borrower.category eq 'PRO'",
"value": "efghi"
},
{
"value": "abcd"
}
]
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
