[Koha-devel] New 'configurations' table (26129)

[Tomas Cohen Arazi]

When I said pattern, I was pointing to some recent devs I've been involved
in, in which there existed a global syspref, and we added
category-spcific overrides (for example password strength enforcement) or
if an itemtype is excluded from LocalHoldsPriority.

In those cases we added a new column to the related table (categories,
itemtypes).

As a general rule, I'd say most of the sysprefs could be moved as 'global'
(i.e. no library, on item type or category) unless there's room to enhance
them to make them per some of the other criterias.
I personally prefer  to keep my dev as-is (it is almost finished and happy
with the smtp_servers table). But there was some room for thinking about a
more general approach to sysprefs. which sometimes are combined with
information from other places and it is not that easy for the end user to
understand the different interactions between them. Take the password
strength sysprefs, and the category-specific overrides. It would be better
to provide a nice UI for setting global and on a per-category basis this.
And we could have some flag to identify the ones to be displayed on the
system preferences pages specifically.

Regarding 'how to choose the right SMTP' server, I think it really depends
on the context. My guess is we should use the library from which the 'From'
attribute is picked. And we will be safe.


El mar., 4 ago. 2020 a las 12:15, Frédéric Demians (<frederic at tamil.fr>)
escribió:

> 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 at 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/
>


-- 
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200804/0e9e9ac0/attachment.htm>