date:20200804

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

2020-08-04 Thread dcook

That was some solid discussion. There are so many times I want to discuss 
things but no one else seems interested in talking heh.

 

Based on my own thoughts and everyone else’s feedback, I was wondering too 
about a few different “configurations” tables. 

 

Or… if we do want to keep tables for individual features, having some type of 
“template” for config_* tables, which would follow the pattern in a predictable 
way, so we could re-use code and otherwise speed up developments.

 

Often, when I’m developing, I debate with myself about the best way of 
implementing a table. But maybe there are many cases where it could use a 
“config_*” template.

 

Maybe we shouldn’t do 1 catch all, but maybe agreeing on some 
conventions/patterns would be a good idea.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel  On Behalf Of 
Tomas Cohen Arazi
Sent: Wednesday, 5 August 2020 5:48 AM
To: Renvoize, Martin 
Cc: Koha Devel 
Subject: Re: [Koha-devel] New 'configurations' table (26129)

 

Thanks everyone for the valuable feedback. I'll leave my 'configurations' table 
bug open in Bugzilla just in case someone wants to keep discussing it or finds 
it useful for their own dev.

 

I will personally focus on finishing the details of my own dev, that does the 
job pretty well as-is :-D

 

Again, thanks everyone!

 

El mar., 4 ago. 2020 a las 16:44, Renvoize, Martin 
(mailto:martin.renvo...@ptfs-europe.com> >) 
escribió:

All valid points raise

 

Tl:Dr

I'll be watching this idea with interest but am currently on the fence as to 
the benefits and drawbacks

 

Spurious mind stream follows

 

At the moment I'm comfortable with the slow progression I'm seeing with circ 
type system preferences migrating unit the circ rules matrix (and that'll be 
more manageable with the new UX that's in the pipe there too).

 

I've felt for a very long time that we could do with some better dependancy 
management in our preferences highlighting how they interact with each other 
and depend upon each other.. but that's another story.

 

As for the general approach taken by Tomas I'm excited by it, but also not 
entirely sure about the filtering criteria matching the existing circ rules 
sets.  I feel like at least some of the Prefs make allot of sense in their own 
tables with a specific UI.

 

.

 

On Tue, 4 Aug 2020, 7:37 pm Tomas Cohen Arazi, mailto:tomasco...@gmail.com> > wrote:

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 (mailto:frede...@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

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

2020-08-04 Thread Tomas Cohen Arazi

Thanks everyone for the valuable feedback. I'll leave my 'configurations'
table bug open in Bugzilla just in case someone wants to keep discussing it
or finds it useful for their own dev.

I will personally focus on finishing the details of my own dev, that does
the job pretty well as-is :-D

Again, thanks everyone!

El mar., 4 ago. 2020 a las 16:44, Renvoize, Martin (<
martin.renvo...@ptfs-europe.com>) escribió:

> All valid points raise
>
> Tl:Dr
> I'll be watching this idea with interest but am currently on the fence as
> to the benefits and drawbacks
>
> Spurious mind stream follows
>
> At the moment I'm comfortable with the slow progression I'm seeing with
> circ type system preferences migrating unit the circ rules matrix (and
> that'll be more manageable with the new UX that's in the pipe there too).
>
> I've felt for a very long time that we could do with some better
> dependancy management in our preferences highlighting how they interact
> with each other and depend upon each other.. but that's another story.
>
> As for the general approach taken by Tomas I'm excited by it, but also not
> entirely sure about the filtering criteria matching the existing circ rules
> sets.  I feel like at least some of the Prefs make allot of sense in their
> own tables with a specific UI.
>
> .
>
> On Tue, 4 Aug 2020, 7:37 pm Tomas Cohen Arazi, 
> wrote:
>
>> 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 ()
>> 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@lists.koha-community.org
>>>

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

2020-08-04 Thread Renvoize, Martin

All valid points raise

Tl:Dr
I'll be watching this idea with interest but am currently on the fence as
to the benefits and drawbacks

Spurious mind stream follows

At the moment I'm comfortable with the slow progression I'm seeing with
circ type system preferences migrating unit the circ rules matrix (and
that'll be more manageable with the new UX that's in the pipe there too).

I've felt for a very long time that we could do with some better dependancy
management in our preferences highlighting how they interact with each
other and depend upon each other.. but that's another story.

As for the general approach taken by Tomas I'm excited by it, but also not
entirely sure about the filtering criteria matching the existing circ rules
sets.  I feel like at least some of the Prefs make allot of sense in their
own tables with a specific UI.

.

On Tue, 4 Aug 2020, 7:37 pm Tomas Cohen Arazi,  wrote:

> 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 ()
> 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@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
> ___
> 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 :

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

2020-08-04 Thread 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 ()
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@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
___
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/

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

2020-08-04 Thread Frédéric Demians

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/

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

2020-08-04 Thread Julian Maurice


Hi Tomas,

I can see the benefits of a per-library, per-itemtype, per-category 
configuration table, but SMTP and Z39.50 servers do not seem to be the 
best example for that : "per-itemtype SMTP servers" does not make sense 
at all, and why would someone need per-library Z39.50 servers ?

Do you have other examples in mind ?

Will the per-category setting rely on the category of the logged-in user 
or the category of the user being worked on (patron checking out an item 
for instance) ? Will it depend on the setting itself (some settings rely 
on the logged-in user, some other settings rely on the user being worked 
on) ? Will it depend on another setting (like item-level_itypes syspref) 
? Will that other setting be configurable per-library ? ...
I'm afraid we will end up with a "configuration hell", even worse than 
what we already have with global system preferences.
At least it should be very clear what each per-thing mean, and we should 
be really careful to not over-complicate configuration.

In this particular example, a `smtp_servers` table seems a lot more simple

Le 03/08/2020 à 19:59, Tomas Cohen Arazi a écrit :

TL;DR;
This email is for getting some feedback about a new table I'm proposing 
to add that implements a pattern I'm seeing more and more often as 
required: global, and per-library, per-item type and per-category 
settings. It can be easily extended with new constraints as well.


Hi all, I wanted to highlight bug 26129 [1] which proposes to add a new 
table, for storing configuration entries. It differs from the 
systempreferences table basically on the ability to set values with 
per-library, per-item type and per-category basis, as well as default 
catch-all.


It is the result of noticing that the smtp_servers table I was going to 
add on bug 22343 [2], could be easily generalized and could become useful.


If someone is willing to do it, we could migrate systempreferences into 
this new table, but that definitely deserves more thinking. The SMTP 
configuration page won't live in the sysprefs page, and so a way to 
differentiate them could be added.


One sample use of this configurations table, could be moving z39.50 
servers there.


[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 

[2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 



--
Tomás Cohen Arazi
Theke Solutions (http://theke.io )
✆ +54 9351 3513384
GPG: B2F3C15F

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



--
Julian Maurice
BibLibre
___
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/

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

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

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

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

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

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

6 matches

Site Navigation

Mail list logo

Footer information