<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Segoe UI Symbol";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>That was some solid discussion. There are so many times I want to discuss things but no one else seems interested in talking heh.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Based on my own thoughts and everyone else’s feedback, I was wondering too about a few different “configurations” tables. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Maybe we shouldn’t do 1 catch all, but maybe agreeing on some conventions/patterns would be a good idea.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>David Cook<o:p></o:p></p><p class=MsoNormal>Systems Librarian<o:p></o:p></p><p class=MsoNormal>Prosentient Systems<o:p></o:p></p><p class=MsoNormal>72/330 Wattle St<o:p></o:p></p><p class=MsoNormal>Ultimo, NSW 2007<o:p></o:p></p><p class=MsoNormal>Australia<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Office: 02 9212 0899<o:p></o:p></p><p class=MsoNormal>Online: 02 8005 0595<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Koha-devel <koha-devel-bounces@lists.koha-community.org> <b>On Behalf Of </b>Tomas Cohen Arazi<br><b>Sent:</b> Wednesday, 5 August 2020 5:48 AM<br><b>To:</b> Renvoize, Martin <martin.renvoize@ptfs-europe.com><br><b>Cc:</b> Koha Devel <koha-devel@lists.koha-community.org><br><b>Subject:</b> Re: [Koha-devel] New 'configurations' table (26129)<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I will personally focus on finishing the details of my own dev, that does the job pretty well as-is :-D<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Again, thanks everyone!<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>El mar., 4 ago. 2020 a las 16:44, Renvoize, Martin (<<a href="mailto:martin.renvoize@ptfs-europe.com">martin.renvoize@ptfs-europe.com</a>>) escribió:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>All valid points raise<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Tl:Dr<o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif'>I'll be watching this idea with interest but am currently on the fence as to the benefits and drawbacks</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Spurious mind stream follows<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>.<o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, 4 Aug 2020, 7:37 pm Tomas Cohen Arazi, <<a href="mailto:tomascohen@gmail.com" target="_blank">tomascohen@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In those cases we added a new column to the related table (categories, itemtypes).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>El mar., 4 ago. 2020 a las 12:15, Frédéric Demians (<<a href="mailto:frederic@tamil.fr" target="_blank">frederic@tamil.fr</a>>) escribió:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>I concur with Julian observations. A configuration selection per<br>library-item_type-category will be too much or not enough depending on the<br>context. We will end up with another table containing zillions of records for<br>trivial things. Tomas, have you considered a hierarchical configuration data<br>structure like the one found in Sublime text editor (I recall you're a Sublime<br>user...) ? We currently also have all those "YAML" configurations that are<br>stored in files (OAI, ElasticSeach) or in system preferences that won't fit in<br>a new library-type-category configuration table. The XML configuration files<br>fall into the same category of data structure.<br><br>Another onservation. You express this need:<br><br> the ability to set values with per-library, per-item type and per-category<br> basis, as well as default catch-all<br><br>We have this need (this 'pattern' as you said) potentially everywhere in Koha.<br>But we also need (1) more, and (2) a clear understanding of how the<br>'catch-all' or the 'fall-back' works.<br><br>(1) We need more (eventually). For example, you may need to combine the item<br>type with the ccode, item homebranch, and borrowr branch, in order to select<br>a claim letter. This could be something like this:<br><br> item.homebranch ne 'MAIN' && item.ccode eq 'EBOOK' &&<br> borrower.country ne 'Monaco' && borrower.branchcode eq 'SCIENCE'<br><br>(2) We need to understand how the various criteria are evaluated and in which<br>order. Sequential order seems reasonable. With this, having an issue, you<br>evaluate 3 criteria in order to select a value:<br><br>[<br> {<br> "criteria": "item.homebranch eq 'MAIN' && borrower.category eq 'ADULT'",<br> "value": "abcd"<br> },<br> {<br> "criteria": "borrower.category eq 'PRO'",<br> "value": "efghi"<br> },<br> {<br> "value": "abcd"<br> }<br>]<br>_______________________________________________<br>Koha-devel mailing list<br><a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br><a href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>Tomás Cohen Arazi<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Theke Solutions (<a href="http://theke.io/" target="_blank">http://theke.io</a>)<br></span><span style='font-size:9.5pt;font-family:"Segoe UI Symbol",sans-serif'>✆</span><span style='font-size:9.5pt'> +54 9351 3513384<br>GPG: B2F3C15F<o:p></o:p></span></p></div></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Koha-devel mailing list<br><a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br><a href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><o:p></o:p></p></blockquote></div><p class=MsoNormal>_______________________________________________<br>Koha-devel mailing list<br><a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br><a href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>Tomás Cohen Arazi<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Theke Solutions (<a href="http://theke.io/" target="_blank">http://theke.io</a>)<br></span><span style='font-size:9.5pt;font-family:"Segoe UI Symbol",sans-serif'>✆</span><span style='font-size:9.5pt'> +54 9351 3513384<br>GPG: B2F3C15F<o:p></o:p></span></p></div></div></div></div></div></div></body></html>