From dcook at prosentient.com.au Mon Aug 3 03:57:20 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 3 Aug 2020 11:57:20 +1000 Subject: [Koha-devel] --username and --password in process_message_queue.pl In-Reply-To: References: Message-ID: <00dc01d66939$6c362b30$44a28190$@prosentient.com.au> Awesome, Tomas! And nope I’ve never used --username or --password with that script. 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: Saturday, 1 August 2020 2:16 AM To: koha-devel Subject: [Koha-devel] --username and --password in process_message_queue.pl Hi everyone. I'm finishing my work to make SMTP something configurable from the UI with multiple options and per-library configs [1]. I am right now tweaking all the places that send emails so they use this configurations. The only place where things aren't clear regarding what to do, is process_message_queue.pl , which has the following parameters: --username --password They are used to authenticate the SMTP request. The current behaviour is that all email-related stuff points to localhost, and those params are used to authenticate the SMTP connection. Does anyone use them? Is is ok to assume they should supersede the ones defined in the new configuration? Have a great weekend you all [1] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From tomascohen at gmail.com Mon Aug 3 19:59:37 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 3 Aug 2020 14:59:37 -0300 Subject: [Koha-devel] New 'configurations' table (26129) Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Aug 4 01:20:44 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 4 Aug 2020 09:20:44 +1000 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: References: Message-ID: <01e601d669ec$b63eb6d0$22bc2470$@prosentient.com.au> I’m intrigued! Honestly, I was looking at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 and I was thinking that it was too bad we didn’t have a more generalizable CRUD setup. Using that “configurations” table could make that a lot easier. I’m not 100% sure what I thought about the db schema design. It doesn’t seem like there is any way to group configuration rows together, so I’m guessing for anything multi-value (like SMTP servers or Z39.50 servers), you’d be storing some JSON as the value? 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: Tuesday, 4 August 2020 4:00 AM To: koha-devel Subject: [Koha-devel] New 'configurations' table (26129) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Tue Aug 4 01:28:49 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 4 Aug 2020 09:28:49 +1000 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: <01e601d669ec$b63eb6d0$22bc2470$@prosentient.com.au> References: <01e601d669ec$b63eb6d0$22bc2470$@prosentient.com.au> Message-ID: <01f501d669ed$d7664de0$8632e9a0$@prosentient.com.au> Actually, something to build into this would be better data validation. The Global System Preferences are terrible when it comes to this. 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 dcook at prosentient.com.au Sent: Tuesday, 4 August 2020 9:21 AM To: 'Tomas Cohen Arazi' ; 'koha-devel' Subject: Re: [Koha-devel] New 'configurations' table (26129) I’m intrigued! Honestly, I was looking at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 and I was thinking that it was too bad we didn’t have a more generalizable CRUD setup. Using that “configurations” table could make that a lot easier. I’m not 100% sure what I thought about the db schema design. It doesn’t seem like there is any way to group configuration rows together, so I’m guessing for anything multi-value (like SMTP servers or Z39.50 servers), you’d be storing some JSON as the value? 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: Tuesday, 4 August 2020 4:00 AM To: koha-devel > Subject: [Koha-devel] New 'configurations' table (26129) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From julian.maurice at biblibre.com Tue Aug 4 14:37:57 2020 From: julian.maurice at biblibre.com (Julian Maurice) Date: Tue, 4 Aug 2020 14:37:57 +0200 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: References: Message-ID: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> 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 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/ > -- Julian Maurice BibLibre From frederic at tamil.fr Tue Aug 4 17:15:07 2020 From: frederic at tamil.fr (=?UTF-8?B?RnLDqWTDqXJpYyBEZW1pYW5z?=) Date: Tue, 4 Aug 2020 17:15:07 +0200 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> References: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> Message-ID: 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" } ] From tomascohen at gmail.com Tue Aug 4 20:36:51 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 4 Aug 2020 15:36:51 -0300 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: References: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> Message-ID: 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 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: From martin.renvoize at ptfs-europe.com Tue Aug 4 21:43:22 2020 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 4 Aug 2020 20:43:22 +0100 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: References: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> Message-ID: 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 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 > _______________________________________________ > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Aug 4 21:48:26 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 4 Aug 2020 16:48:26 -0300 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: References: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> Message-ID: 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.renvoize at 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 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 >> _______________________________________________ >> 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/ >> > _______________________________________________ > 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: From dcook at prosentient.com.au Wed Aug 5 02:39:55 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 5 Aug 2020 10:39:55 +1000 Subject: [Koha-devel] New 'configurations' table (26129) In-Reply-To: References: <1698705f-fcd5-503e-f3a8-bef5dce02c0a@biblibre.com> Message-ID: <032d01d66ac0$f0e2f880$d2a8e980$@prosentient.com.au> 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 ( >) 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 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 _______________________________________________ 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/ _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Wed Aug 5 09:28:47 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 5 Aug 2020 17:28:47 +1000 Subject: [Koha-devel] Move .tt files out of "htdocs" and into separate "tt" or "templates" directory Message-ID: <03f301d66afa$0ed13c10$2c73b430$@prosentient.com.au> Hi all, We should move all the .tt files out of the /usr/share/koha/intranet/htdocs and /usr/share/koha/opac/htdocs directories and put them somewhere private like /usr/share/koha/tt or /usr/share/koha/templates. At the moment, Apache is serving these files to anyone who asks for them, and it really shouldn't. Having these files in the "htdocs" directories also makes it harder to manage actual static assets that are served to Koha users. I've opened a Bugzilla report for it: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26140 This early in the release cycle, it could be great to get this done, so that we have a chance to work out any kinks before November. What do people think? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Thu Aug 6 13:06:24 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 6 Aug 2020 21:06:24 +1000 Subject: [Koha-devel] Use DateTime::Format::Strptime in Koha::DateUtils Message-ID: <055301d66be1$a1043730$e30ca590$@prosentient.com.au> Hi all, I needed to parse a string into a DateTime object, so I decided to take a look at Koha::DateUtils, and I was surprised to see that we're parsing dates the hard way. We really should look at using DateTime::Format::Strptime instead. I use it in other Perl projects, and it makes life much easier. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From jonathan.druart at bugs.koha-community.org Thu Aug 6 14:11:12 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 6 Aug 2020 14:11:12 +0200 Subject: [Koha-devel] Use DateTime::Format::Strptime in Koha::DateUtils In-Reply-To: <055301d66be1$a1043730$e30ca590$@prosentient.com.au> References: <055301d66be1$a1043730$e30ca590$@prosentient.com.au> Message-ID: What do you suggest exactly? To replace the 3 regexs by a new module? Or getting rid of the dateformat syspref and use the locales from the client instead? Le jeu. 6 août 2020 à 13:06, a écrit : > > Hi all, > > > > I needed to parse a string into a DateTime object, so I decided to take a look at Koha::DateUtils, and I was surprised to see that we’re parsing dates the hard way. We really should look at using DateTime::Format::Strptime instead. I use it in other Perl projects, and it makes life much easier. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > _______________________________________________ > 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/ From dcook at prosentient.com.au Thu Aug 6 14:18:26 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 6 Aug 2020 22:18:26 +1000 Subject: [Koha-devel] Current state of unit testing Message-ID: <055f01d66beb$b1235e20$136a1a60$@prosentient.com.au> Hi all, I gave Test::DBIx::Class a try tonight, as it seems super awesome, but unfortunately encountered the following error due to C4::Biblio::_koha_add_biblio() using a MySQLism in its SQL: C4::Biblio::_koha_add_biblio(): DBI Exception: DBD::SQLite::db prepare failed: near "SET": syntax error at /kohadevbox/koha/C4/Biblio.pm line 219 That makes me think my only option is to turn off Autocommit and rollback my testing work. Does anyone else have a better alternative for unit tests in Koha? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From oleonard at myacpl.org Fri Aug 7 01:55:33 2020 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 6 Aug 2020 19:55:33 -0400 Subject: [Koha-devel] An idea for consolidating staff interface header search forms In-Reply-To: <08fe01d65b1a$94d6f100$be84d300$@prosentient.com.au> References: <9db879ee-4a32-3c94-93cd-5652fe7f70f1@web.de> <5b7f836b-b67d-b3ed-ea06-ab86b9ad21fb@web.de> <5a223b01-3955-b53c-1e81-4a82a8acebd3@biblibre.com> <08fe01d65b1a$94d6f100$be84d300$@prosentient.com.au> Message-ID: On Wed, Jul 15, 2020 at 10:41 PM wrote: > > Yeah, I'm not a fan of a single big file either. ... > It looks like that 1 file is 764 lines long For comparison, columns_settings.yml is currently 1434 lines long. -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org From hblancoca at gmail.com Fri Aug 7 01:59:47 2020 From: hblancoca at gmail.com (Humberto Blanco Castillo) Date: Thu, 6 Aug 2020 18:59:47 -0500 Subject: [Koha-devel] SIP2 Error 20.05 Message-ID: Hi, I configure SIP2 , and the service load well *root at srvcbkohac01:/var/log/koha/catalogo# netstat -an | grep ":8023"tcp 0 0 0.0.0.0:8023 0.0.0.0:* LISTEN root at srvcbkohac01:/var/log/koha/catalogo# netstat -an | grep ":6001"tcp 0 0 0.0.0.0:6001 0.0.0.0:* LISTEN root at srvcbkohac01:/var/log/koha/catalogo# koha-sip --status catalogo[ ok ] SIP server running for catalogo:.* My selfchek machines are not connecting to SIP server. And if i want to try do telnet localhost 6001 the server open an closes the connection inmediately *root at srvcbkohac01:/var/log/koha/catalogo# telnet localhost 6001Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Connection closed by foreign host.* cannot permit any command. My server is Debian "Debian GNU/Linux 10 (buster)", and the firewall its not enabled. My server params an port are the following, those are working fine inkoha version 3.22: * * Really appreciate if have any idea ... Humberto -- Cordialmente, Humberto Blanco -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.campbell at ptfs-europe.com Fri Aug 7 11:06:56 2020 From: colin.campbell at ptfs-europe.com (Campbell, Colin) Date: Fri, 7 Aug 2020 10:06:56 +0100 Subject: [Koha-devel] SIP2 Error 20.05 In-Reply-To: References: Message-ID: You appear to be telneting to the port configured as raw rather than the telnet port (8023), It will disconnect if you dont send a sip login request Colin On Fri, 7 Aug 2020 at 01:00, Humberto Blanco Castillo wrote: > > Hi, > I configure SIP2 , and the service load well > root at srvcbkohac01:/var/log/koha/catalogo# netstat -an | grep ":8023" > tcp 0 0 0.0.0.0:8023 0.0.0.0:* LISTEN > root at srvcbkohac01:/var/log/koha/catalogo# netstat -an | grep ":6001" > tcp 0 0 0.0.0.0:6001 0.0.0.0:* LISTEN > root at srvcbkohac01:/var/log/koha/catalogo# koha-sip --status catalogo > [ ok ] SIP server running for catalogo:. > > My selfchek machines are not connecting to SIP server. And if i want to try do telnet localhost 6001 the server open an closes the connection inmediately > > root at srvcbkohac01:/var/log/koha/catalogo# telnet localhost 6001 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Connection closed by foreign host. > > cannot permit any command. > > My server is Debian "Debian GNU/Linux 10 (buster)", and the firewall its not enabled. > > My server params an port are the following, those are working fine inkoha version 3.22: > > min_servers='10' > min_spare_servers='5' > log_file='Sys::Syslog' > syslog_ident='koha_sip' > syslog_facility='local6' > ipv='4' > /> > > > > port="8023/tcp" > transport="telnet" > protocol="SIP/2.00" > timeout="120" /> > > > port="6001/tcp" > transport="RAW" > protocol="SIP/2.00" > client_timeout="600" > timeout="600" /> > > > Really appreciate if have any idea ... > > Humberto > > > > > > > -- > Cordialmente, > > > Humberto Blanco > _______________________________________________ > 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/ From dcook at prosentient.com.au Fri Aug 7 07:10:13 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 7 Aug 2020 15:10:13 +1000 Subject: [Koha-devel] An idea for consolidating staff interface header search forms In-Reply-To: References: <9db879ee-4a32-3c94-93cd-5652fe7f70f1@web.de> <5b7f836b-b67d-b3ed-ea06-ab86b9ad21fb@web.de> <5a223b01-3955-b53c-1e81-4a82a8acebd3@biblibre.com> <08fe01d65b1a$94d6f100$be84d300$@prosentient.com.au> Message-ID: <061701d66c79$082f79a0$188e6ce0$@prosentient.com.au> I don't like columns_settings.yml either heh, although that's also a bit of a different case, since it's just a YAML serialization of 1 large data structure, which would be easy to validate. In this case, we'd be having 1 huge template file with much more complex syntax. But... may as well go ahead and do it. I can't think of any reasons not to that would be real blockers. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Owen Leonard Sent: Friday, 7 August 2020 9:56 AM To: Koha Devel Subject: Re: [Koha-devel] An idea for consolidating staff interface header search forms On Wed, Jul 15, 2020 at 10:41 PM wrote: > > Yeah, I'm not a fan of a single big file either. ... > It looks like that 1 file is 764 lines long For comparison, columns_settings.yml is currently 1434 lines long. -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org _______________________________________________ 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Fri Aug 7 06:25:16 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 7 Aug 2020 14:25:16 +1000 Subject: [Koha-devel] Upgrading Debian 8 to Debian 9 breaks Koha 18.05 (also couldn't install Koha 20.05 on Ubuntu 18.04) Message-ID: <05fa01d66c72$c08b8950$41a29bf0$@prosentient.com.au> Hi all, Since Debian 8 is EOL, it's past time to upgrade to Debian 9 (at least). However, upgrading from Debian 8 to Debian 9 uninstalls Koha 18.05. Worse, when I try to re-install Koha, I get the following errors now (although I didn't a month ago on a similar server): The following packages have unmet dependencies: koha-common : Depends: libhttp-oai-perl (< 4.0) but 4.03-2 is to be installed or libhttp-oai-3.27-perl but it is not installable Depends: libmojolicious-plugin-openapi-perl but it is not installable Depends: libpdf-fromhtml-perl but it is not installable Depends: libtemplate-plugin-htmltotext-perl but it is not installable E: Unable to correct problems, you have held broken packages. (Also, last time we tried to install Koha 20.05 on Ubuntu 18.04, we encountered the problem with https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25886.) What's going on with the Koha packaging these days? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Fri Aug 7 08:01:08 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 7 Aug 2020 16:01:08 +1000 Subject: [Koha-devel] Best practices for using Koha APIs server-side by Koha Message-ID: <062601d66c80$24dff8c0$6e9fea40$@prosentient.com.au> Hi all, I mostly see Koha APIs being used client-side by Koha using cookie authentication. I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and used by a third-party system, which is great. However, what about when we have server-side Koha components that want to use Koha APIs? (I suppose you could set up a user for that component, but it could always be deleted by an overzealous librarian.) Or should we only be using a Message Broker (like RabbitMQ) for passing messages among Koha server-side components? (That would require more of a service oriented architecture of course, which we don't have in place, while we do have a HTTP API in place.) What are your thoughts? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From katrin.fischer.83 at web.de Fri Aug 7 13:39:26 2020 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Fri, 7 Aug 2020 13:39:26 +0200 Subject: [Koha-devel] Upgrading Debian 8 to Debian 9 breaks Koha 18.05 (also couldn't install Koha 20.05 on Ubuntu 18.04) In-Reply-To: <05fa01d66c72$c08b8950$41a29bf0$@prosentient.com.au> References: <05fa01d66c72$c08b8950$41a29bf0$@prosentient.com.au> Message-ID: <08ad5af7-919c-39e8-2f8e-50dc5e385e42@web.de> For Ubuntu 18.04, please check: https://wiki.koha-community.org/wiki/Koha_on_Debian#Support_for_Koha_on_older_versions_of_Debian.2FUbuntu_.28Debian_8.2C_Ubuntu_18.04.2C_Ubuntu_16.04.29 ? On 07.08.20 06:25, dcook at prosentient.com.au wrote: > > Hi all, > > Since Debian 8 is EOL, it’s past time to upgrade to Debian 9 (at > least). However, upgrading from Debian 8 to Debian 9 uninstalls Koha > 18.05. > > Worse, when I try to re-install Koha, I get the following errors now > (although I didn’t a month ago on a similar server): > > The following packages have unmet dependencies: > > koha-common : Depends: libhttp-oai-perl (< 4.0) but 4.03-2 is to be > installed or > > libhttp-oai-3.27-perl but it is not installable > >                Depends: libmojolicious-plugin-openapi-perl but it is > not installable > >                Depends: libpdf-fromhtml-perl but it is not installable > >                Depends: libtemplate-plugin-htmltotext-perl but it is > not installable > > E: Unable to correct problems, you have held broken packages. > > (Also, last time we tried to install Koha 20.05 on Ubuntu 18.04, we > encountered the problem with > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25886.) > > What’s going on with the Koha packaging these days? > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > _______________________________________________ > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Fri Aug 7 15:26:46 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 7 Aug 2020 15:26:46 +0200 Subject: [Koha-devel] Maintenance of the mailing list server Message-ID: Hello devs, I have been in touch with Biblibre's sysop, Laurent. We are planning an upgrade of the mailing list server (move), in order to fix the problems we are facing for several months. It will make all the mailing lists listed there unavailable: https://lists.koha-community.org/cgi-bin/mailman/listinfo (all Koha MLs but the general one koha at lists.katipo.co.nz) It will be done on August 11th (Tuesday) starting at 7 UTC (for about 1 or 2 hours). I will send an update message when it is finished. Cheers, Jonathan From tomascohen at gmail.com Fri Aug 7 15:45:14 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 7 Aug 2020 10:45:14 -0300 Subject: [Koha-devel] Maintenance of the mailing list server In-Reply-To: References: Message-ID: Thanks for the heads up! El vie., 7 ago. 2020 a las 10:27, Jonathan Druart (< jonathan.druart at bugs.koha-community.org>) escribió: > Hello devs, > > I have been in touch with Biblibre's sysop, Laurent. We are planning > an upgrade of the mailing list server (move), in order to fix the > problems we are facing for several months. > > It will make all the mailing lists listed there unavailable: > https://lists.koha-community.org/cgi-bin/mailman/listinfo (all Koha > MLs but the general one koha at lists.katipo.co.nz) > > It will be done on August 11th (Tuesday) starting at 7 UTC (for about > 1 or 2 hours). > > I will send an update message when it is finished. > > Cheers, > Jonathan > _______________________________________________ > 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: From michael.hafen at washk12.org Fri Aug 7 18:45:45 2020 From: michael.hafen at washk12.org (Michael Hafen (TECH)) Date: Fri, 7 Aug 2020 10:45:45 -0600 Subject: [Koha-devel] Best practices for using Koha APIs server-side by Koha In-Reply-To: <062601d66c80$24dff8c0$6e9fea40$@prosentient.com.au> References: <062601d66c80$24dff8c0$6e9fea40$@prosentient.com.au> Message-ID: Maybe I'm lacking in imagination, but I can only think of two cases where a Koha to Koha api would be useful: scheduled tasks (cron, et. all), and command line scripts. I think in both of these cases it's feasible to avoid auth entirely since it is basically jumping right into Koha at the control level (assuming an MCV approach). As someone who has a deployment of Koha heavily dependent on IndependentBranches mode, I find I have to watch for %userenv{branch}, but that's for rare cases in which branch can't be taken from the data being operated on. The only other thing I can think of would be something like notices wanting to take a user's preferred language, and pull a language specific template (do we even do that at this point?). Please enlighten me on your use cases, I'm probably missing something. On Fri, Aug 7, 2020 at 5:09 AM wrote: > Hi all, > > > > I mostly see Koha APIs being used client-side by Koha using cookie > authentication. > > > > I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and > used by a third-party system, which is great. > > > > However, what about when we have server-side Koha components that want to > use Koha APIs? (I suppose you could set up a user for that component, but > it could always be deleted by an overzealous librarian.) > > > > Or should we only be using a Message Broker (like RabbitMQ) for passing > messages among Koha server-side components? (That would require more of a > service oriented architecture of course, which we don’t have in place, > while we do have a HTTP API in place.) > > > > What are your thoughts? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > _______________________________________________ > 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/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Aug 10 02:59:59 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 10 Aug 2020 10:59:59 +1000 Subject: [Koha-devel] Best practices for using Koha APIs server-side by Koha In-Reply-To: References: <062601d66c80$24dff8c0$6e9fea40$@prosentient.com.au> Message-ID: <06c501d66eb1$9257e970$b707bc50$@prosentient.com.au> Hi Michael, Another case where a Koha to Koha API would be useful is in the use of additional service (or microservices). At the moment, the SIP server is closely coupled with Koha, but it could just as easily be a separate component that used HTTP APIs (rather than internal Perl APIs) to work with Koha. You could argue that you could avoid auth (although I don’t understand your interpretation of MCV in this case), but that would be out of convenience rather than security. You could argue that you just protect the edges of your host (via a firewall for instance), but what about if that service isn’t running on the same host? Then you need to open a hole in that firewall. Then how do you protect that hole? Just using IP addresses isn’t going to work very well. You’ll want to have authentication and authorization, especially when your application is part of a larger multi-vendor cloud ecosystem for instance. The particular use case I have in mind is for a OAI-PMH harvester service. There could be 1 OAI-PMH harvester servicing many Koha instances. It could be running in its own local Docker container or its own local virtual machine or even as a remote Internet service controlled by a different organisation. It’s only relation to Koha is in terms of accepting JSON serialized harvesting requests and sending MARCXML records for Koha to import. For integrating the services, we could use point-to-point (P2P) communication via the HTTP APIs. That’s pretty much the only option we have at the moment. However, Koha will be adding RabbitMQ as a Message Broker (for a hub-and-spoke model), so Koha and the other services could have their own credentials to authenticate against the Message Broker, and use it for communication. Both models have their pros and cons. My current plan is to use https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 to provide more stable Koha users and https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25905 to provide an OAI-PMH ingestion endpoint to Koha. Then I’ll implement the OAI-PMH harvester separate from Koha (with a Koha plugin initially to send OAI-PMH harvesting requests to the OAI-PMH harvester service), which sends downloaded records to the Koha API for the Koha that requested the harvest. This approach will have some friction though. I’ll have to add a Koha user, share the Koha user credentials to the OAI-PMH service, register the Koha instance in the OAI-PMH service, and share the OAI-PMH credentials with Koha. That process could be unnecessary using a Message Broker. Another option would be to set up single sign on (SSO) with P2P where Koha and the OAI-PMH service delegate AuthN (and even potentially AuthZ) to an identity provider. That would make things smoother but also more complicated. If I wanted to more tightly integrate with Koha, I suppose I could create a koha-oaipmh CLI tool which automates the user creation and credential sharing I suppose. The other benefit of using the Message Broker is that you don’t have to manage IP addresses and ports. I should look at the koha-sip tool again, but I don’t know how it handles setting up different ports for each different Koha instance. In any case, I’m keen to get input from others on system design. On one hand, I’d like something that easily works for everyone, and on the other hand I’d like something that works really well. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Michael Hafen (TECH) Sent: Saturday, 8 August 2020 2:46 AM To: David Cook Cc: Koha Devel ; Kyle Hall ; Tomas Cohen Arazi Subject: Re: [Koha-devel] Best practices for using Koha APIs server-side by Koha Maybe I'm lacking in imagination, but I can only think of two cases where a Koha to Koha api would be useful: scheduled tasks (cron, et. all), and command line scripts. I think in both of these cases it's feasible to avoid auth entirely since it is basically jumping right into Koha at the control level (assuming an MCV approach). As someone who has a deployment of Koha heavily dependent on IndependentBranches mode, I find I have to watch for %userenv{branch}, but that's for rare cases in which branch can't be taken from the data being operated on. The only other thing I can think of would be something like notices wanting to take a user's preferred language, and pull a language specific template (do we even do that at this point?). Please enlighten me on your use cases, I'm probably missing something. On Fri, Aug 7, 2020 at 5:09 AM > wrote: Hi all, I mostly see Koha APIs being used client-side by Koha using cookie authentication. I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and used by a third-party system, which is great. However, what about when we have server-side Koha components that want to use Koha APIs? (I suppose you could set up a user for that component, but it could always be deleted by an overzealous librarian.) Or should we only be using a Message Broker (like RabbitMQ) for passing messages among Koha server-side components? (That would require more of a service oriented architecture of course, which we don’t have in place, while we do have a HTTP API in place.) What are your thoughts? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 _______________________________________________ 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/ -- Michael Hafen Washington County School District Technology Department Systems Analyst -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From michael.hafen at washk12.org Mon Aug 10 18:38:09 2020 From: michael.hafen at washk12.org (Michael Hafen (TECH)) Date: Mon, 10 Aug 2020 10:38:09 -0600 Subject: [Koha-devel] Best practices for using Koha APIs server-side by Koha In-Reply-To: <06c501d66eb1$9257e970$b707bc50$@prosentient.com.au> References: <062601d66c80$24dff8c0$6e9fea40$@prosentient.com.au> <06c501d66eb1$9257e970$b707bc50$@prosentient.com.au> Message-ID: You've got me there, I wasn't even thinking about third-party services like OAI-PMH. My comment about avoiding auth is only really feasible for first-party or locally developed cli scripts. (I could say second-party there, but that's just silly.) Third-party services definitely need to authen, and probably authiz too. A message broker would be handy for that, where you probably have one set of credentials that are shared by any services talking on that queue. oAuth can do that too, but you'd have to build a way for the client id and secret to be stored by both services in lieu of a username and password. Which seems basically the same to me as having a username and password. On the one hand we'd have to build a connector between the message broker and the Koha api's. On the other hand we'd have to build oAuth access token handling into the existing api's. (where the appropriate api's already exist.) On Sun, Aug 9, 2020 at 7:00 PM wrote: > Hi Michael, > > > > Another case where a Koha to Koha API would be useful is in the use of > additional service (or microservices). At the moment, the SIP server is > closely coupled with Koha, but it could just as easily be a separate > component that used HTTP APIs (rather than internal Perl APIs) to work with > Koha. > > > > You could argue that you could avoid auth (although I don’t understand > your interpretation of MCV in this case), but that would be out of > convenience rather than security. You could argue that you just protect the > edges of your host (via a firewall for instance), but what about if that > service isn’t running on the same host? Then you need to open a hole in > that firewall. Then how do you protect that hole? Just using IP addresses > isn’t going to work very well. You’ll want to have authentication and > authorization, especially when your application is part of a larger > multi-vendor cloud ecosystem for instance. > > > > The particular use case I have in mind is for a OAI-PMH harvester service. > There could be 1 OAI-PMH harvester servicing many Koha instances. It could > be running in its own local Docker container or its own local virtual > machine or even as a remote Internet service controlled by a different > organisation. It’s only relation to Koha is in terms of accepting JSON > serialized harvesting requests and sending MARCXML records for Koha to > import. > > > > For integrating the services, we could use point-to-point (P2P) > communication via the HTTP APIs. That’s pretty much the only option we have > at the moment. However, Koha will be adding RabbitMQ as a Message Broker > (for a hub-and-spoke model), so Koha and the other services could have > their own credentials to authenticate against the Message Broker, and use > it for communication. Both models have their pros and cons. > > > > My current plan is to use > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 to > provide more stable Koha users and > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25905 to > provide an OAI-PMH ingestion endpoint to Koha. Then I’ll implement the > OAI-PMH harvester separate from Koha (with a Koha plugin initially to send > OAI-PMH harvesting requests to the OAI-PMH harvester service), which sends > downloaded records to the Koha API for the Koha that requested the harvest. > This approach will have some friction though. I’ll have to add a Koha user, > share the Koha user credentials to the OAI-PMH service, register the Koha > instance in the OAI-PMH service, and share the OAI-PMH credentials with > Koha. That process could be unnecessary using a Message Broker. Another > option would be to set up single sign on (SSO) with P2P where Koha and the > OAI-PMH service delegate AuthN (and even potentially AuthZ) to an identity > provider. That would make things smoother but also more complicated. > > > > If I wanted to more tightly integrate with Koha, I suppose I could create > a koha-oaipmh CLI tool which automates the user creation and credential > sharing I suppose. > > > > The other benefit of using the Message Broker is that you don’t have to > manage IP addresses and ports. I should look at the koha-sip tool again, > but I don’t know how it handles setting up different ports for each > different Koha instance. > > > > In any case, I’m keen to get input from others on system design. On one > hand, I’d like something that easily works for everyone, and on the other > hand I’d like something that works really well. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > *From:* Michael Hafen (TECH) > *Sent:* Saturday, 8 August 2020 2:46 AM > *To:* David Cook > *Cc:* Koha Devel ; Kyle Hall < > kyle at bywatersolutions.com>; Tomas Cohen Arazi > *Subject:* Re: [Koha-devel] Best practices for using Koha APIs > server-side by Koha > > > > Maybe I'm lacking in imagination, but I can only think of two cases where > a Koha to Koha api would be useful: scheduled tasks (cron, et. all), and > command line scripts. I think in both of these cases it's feasible to > avoid auth entirely since it is basically jumping right into Koha at the > control level (assuming an MCV approach). As someone who has a deployment > of Koha heavily dependent on IndependentBranches mode, I find I have to > watch for %userenv{branch}, but that's for rare cases in which branch can't > be taken from the data being operated on. The only other thing I can think > of would be something like notices wanting to take a user's preferred > language, and pull a language specific template (do we even do that at this > point?). > > Please enlighten me on your use cases, I'm probably missing something. > > > > > > On Fri, Aug 7, 2020 at 5:09 AM wrote: > > Hi all, > > > > I mostly see Koha APIs being used client-side by Koha using cookie > authentication. > > > > I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and > used by a third-party system, which is great. > > > > However, what about when we have server-side Koha components that want to > use Koha APIs? (I suppose you could set up a user for that component, but > it could always be deleted by an overzealous librarian.) > > > > Or should we only be using a Message Broker (like RabbitMQ) for passing > messages among Koha server-side components? (That would require more of a > service oriented architecture of course, which we don’t have in place, > while we do have a HTTP API in place.) > > > > What are your thoughts? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > _______________________________________________ > 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/ > > > > -- > > Michael Hafen > > Washington County School District Technology Department > > Systems Analyst > -- Michael Hafen Washington County School District Technology Department Systems Analyst -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Aug 11 01:50:24 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 11 Aug 2020 09:50:24 +1000 Subject: [Koha-devel] Public vs Private/Admin API Message-ID: <07fa01d66f71$03f65070$0be2f150$@prosentient.com.au> Hi all, I've been thinking a little about API security. When I look at http://localhost:8081/api/v1/.html, I see every API route we define in Koha. Do we really want all of these APIs to be accessible to any API consumer? In many cases, I imagine we only want Staff Interface users (or approved third-party tools) using a lot of these API routes. At the moment, if someone cracks the password of an admin user on the OPAC, they'd then be able to access admin APIs via the OPAC site. That seems suboptimal to me. In theory, breaching the OPAC should have a small blast radius that only affects one user. In practice, if someone breaches the OPAC with an admin user, the blast radius can still be large. Based on https://www.keycloak.org/docs/latest/server_admin/index.html#admin-endpoints -and-console, it could be good to have separate admin API and public API interfaces, which can then be configured and protected differently. I suppose a person could IP restrict the API at the moment and just allow public access to /api/v1/public/ routes. I suppose I just wonder about having more restrictive defaults, although in the Keycloak case the defaults are permissive. Anyway, just sharing my thoughts on this one. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From jonathan.druart at bugs.koha-community.org Tue Aug 11 10:20:49 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 11 Aug 2020 10:20:49 +0200 Subject: [Koha-devel] Maintenance of the mailing list server In-Reply-To: References: Message-ID: It's done now :) Le ven. 7 août 2020 à 15:26, Jonathan Druart a écrit : > > Hello devs, > > I have been in touch with Biblibre's sysop, Laurent. We are planning > an upgrade of the mailing list server (move), in order to fix the > problems we are facing for several months. > > It will make all the mailing lists listed there unavailable: > https://lists.koha-community.org/cgi-bin/mailman/listinfo (all Koha > MLs but the general one koha at lists.katipo.co.nz) > > It will be done on August 11th (Tuesday) starting at 7 UTC (for about > 1 or 2 hours). > > I will send an update message when it is finished. > > Cheers, > Jonathan From dcook at prosentient.com.au Wed Aug 12 02:49:43 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 12 Aug 2020 10:49:43 +1000 Subject: [Koha-devel] Assigning TCP ports to per-instance Koha services (e.g. koha-sip) Message-ID: <091b01d67042$77f0f1c0$67d2d540$@prosentient.com.au> Hi all, I've noticed that "koha-sip" will copy /etc/koha/SIPconfig.xml into /etc/koha/sites/${name}/SIPconfig.xml, but it retains the default port of 6001. Obviously, only 1 service can bind to port 6001 inside the same network namespace, so that's only going to work once, and any following "koha-sip --enable" will need manual intervention after. Is this a convention that we should expect for all current and future per-instance Koha services using TCP ports? Or should we be thinking about ways of dynamically allocating free ports? I suppose that most multi-Koha installations will have a vendor/service provider who can easily configure backend systems, whereas many organisations without technical expertise are more likely to run only 1 Koha instance (and thus benefit from single hard-coded defaults). So maybe just hard-coding a default into a per-instance Koha service makes sense? Or having an option on CLI scripts like koha-sip to define a port (to ease things for vendors) while leaving the default for users with less complex requirements? Just curious what people think. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From monica.benavides at rm.edu Tue Aug 11 21:48:15 2020 From: monica.benavides at rm.edu (Monica Benavides) Date: Tue, 11 Aug 2020 13:48:15 -0600 Subject: [Koha-devel] z39.50 INIT 1020 error Message-ID: Has anyone encountered an INIT 1020 error when using z39.50? If so, what was causing the error and how did you fix it? info:srw/diagnostic/l/2 session_shared: target closed connection during init System temporarily unavailable This is all I know regarding the description of the error. 2.2. Init Number Description Recommended display 1020 Init/AC: System temporarily unavailable System temporarily available (ref. 1020) Code Meaning Addinfo 1020 Init/AC: System temporarily unavailable when it's expected back up -- *Monica Benavides* *Library Assistant/Testing Center Coordinator* –––––––––––––––––––––––––––––––––––––––––––––––––––– *Rocky Mountain University of Health Professions* 122 East 1700 South, Building 3, Provo, Utah 84606 Direct: 385.375.8772 *|* Campus: 801.375.5125 –––––––––––––––––––––––––––––––––––––––––––––––––––– *Stay connected, learn more!* Blog | Facebook | Twitter | YouTube | rm.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at libriotech.no Wed Aug 12 09:23:09 2020 From: magnus at libriotech.no (Magnus Enger) Date: Wed, 12 Aug 2020 09:23:09 +0200 Subject: [Koha-devel] Assigning TCP ports to per-instance Koha services (e.g. koha-sip) In-Reply-To: <091b01d67042$77f0f1c0$67d2d540$@prosentient.com.au> References: <091b01d67042$77f0f1c0$67d2d540$@prosentient.com.au> Message-ID: <25dc75c7-0f79-8605-86dd-9703d7dfbe73@libriotech.no> Den 12.08.2020 02:49, skrev dcook at prosentient.com.au: > So maybe just hard-coding a default into a per-instance Koha service makes > sense? Or having an option on CLI scripts like koha-sip to define a port (to > ease things for vendors) while leaving the default for users with less > complex requirements? A --port command line option to koha-sip, with a sane default if not activated, sounds like an excellenet idea to me! Best regards, Magnus Libriotech AS From dcook at prosentient.com.au Thu Aug 13 03:58:36 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 13 Aug 2020 11:58:36 +1000 Subject: [Koha-devel] Assigning TCP ports to per-instance Koha services (e.g. koha-sip) In-Reply-To: <25dc75c7-0f79-8605-86dd-9703d7dfbe73@libriotech.no> References: <091b01d67042$77f0f1c0$67d2d540$@prosentient.com.au> <25dc75c7-0f79-8605-86dd-9703d7dfbe73@libriotech.no> Message-ID: <0a7701d67115$420b0a40$c6211ec0$@prosentient.com.au> Thanks, Magnus. I've opened up the following report for it: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26198 David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Magnus Enger Sent: Wednesday, 12 August 2020 5:23 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Assigning TCP ports to per-instance Koha services (e.g. koha-sip) Den 12.08.2020 02:49, skrev dcook at prosentient.com.au: > So maybe just hard-coding a default into a per-instance Koha service > makes sense? Or having an option on CLI scripts like koha-sip to > define a port (to ease things for vendors) while leaving the default > for users with less complex requirements? A --port command line option to koha-sip, with a sane default if not activated, sounds like an excellenet idea to me! Best regards, Magnus Libriotech AS _______________________________________________ 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From tomascohen at gmail.com Thu Aug 13 04:40:47 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 12 Aug 2020 23:40:47 -0300 Subject: [Koha-devel] Assigning TCP ports to per-instance Koha services (e.g. koha-sip) In-Reply-To: <0a7701d67115$420b0a40$c6211ec0$@prosentient.com.au> References: <091b01d67042$77f0f1c0$67d2d540$@prosentient.com.au> <25dc75c7-0f79-8605-86dd-9703d7dfbe73@libriotech.no> <0a7701d67115$420b0a40$c6211ec0$@prosentient.com.au> Message-ID: We should definitely make everything configurable through option switched as much as possible. El mié., 12 de agosto de 2020 22:59, escribió: > Thanks, Magnus. > > I've opened up the following report for it: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26198 > > David Cook > Software Engineer > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Online: 02 8005 0595 > > -----Original Message----- > From: Koha-devel On Behalf > Of Magnus Enger > Sent: Wednesday, 12 August 2020 5:23 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Assigning TCP ports to per-instance Koha > services (e.g. koha-sip) > > Den 12.08.2020 02:49, skrev dcook at prosentient.com.au: > > So maybe just hard-coding a default into a per-instance Koha service > > makes sense? Or having an option on CLI scripts like koha-sip to > > define a port (to ease things for vendors) while leaving the default > > for users with less complex requirements? > > A --port command line option to koha-sip, with a sane default if not > activated, sounds like an excellenet idea to me! > > Best regards, > Magnus > Libriotech AS > _______________________________________________ > 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/ > > _______________________________________________ > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Fri Aug 14 06:03:46 2020 From: kohanews at gmail.com (Koha Newsletter) Date: Thu, 13 Aug 2020 21:03:46 -0700 Subject: [Koha-devel] Call for news: August 2020 Koha Newsletter Message-ID: <050FB8DF-6335-4804-B436-84D6FE51996B@gmail.com> I'm collecting news for the August newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter From aleisha at catalyst.net.nz Mon Aug 17 02:18:55 2020 From: aleisha at catalyst.net.nz (Aleisha Amohia) Date: Mon, 17 Aug 2020 12:18:55 +1200 Subject: [Koha-devel] String freeze for 19.11.x Message-ID: Hi all, String freeze will go into effect end of on Tuesday 18 August 2020 for the 19.11.x maintenance branch. 19.11.09 release scheduled for Tuesday 25 August 2020. Thanks -- Aleisha Amohia (she/her) Koha Developer Catalyst IT - Expert Open Source Solutions From mjr at phonecoop.coop Mon Aug 17 15:15:52 2020 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 17 Aug 2020 14:15:52 +0100 Subject: [Koha-devel] Move .tt files out of "htdocs" and into separate "tt" or "templates" directory In-Reply-To: <03f301d66afa$0ed13c10$2c73b430$@prosentient.com.au> References: <03f301d66afa$0ed13c10$2c73b430$@prosentient.com.au> Message-ID: <20200817141552.2ee6248b@bletchley.towers.org.uk> On Wed, 5 Aug 2020 17:28:47 +1000 wrote: > We should move all the .tt files out of > the /usr/share/koha/intranet/htdocs and /usr/share/koha/opac/htdocs > directories and put them somewhere private like /usr/share/koha/tt > or /usr/share/koha/templates. > > At the moment, Apache is serving these files to anyone who asks for > them, and it really shouldn't. Why shouldn't it? Do they contain anything sensitive that people couldn't discover by looking in the koha sources? > Having these files in the "htdocs" directories also makes it harder to > manage actual static assets that are served to Koha users. That seems like a far stronger reason not to do it. > I've opened a Bugzilla report for it: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26140 Cool. Thanks. Regards, -- MJR http://mjr.towers.org.uk/ Member of http://www.software.coop/ (but this email is my personal view only) From victor at tuxayo.net Mon Aug 17 21:59:15 2020 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Mon, 17 Aug 2020 21:59:15 +0200 Subject: [Koha-devel] Time to translate: string freeze for 19.05.x has begun Message-ID: <03877d08-733b-110e-8567-543a1ac842ec@tuxayo.net> Hi, saluton, hola, bonjour, String freeze will be into effect tomorrow 18 August 2020 for the 19.05.x maintenance branch. (as well as for the other branches) The 19.05.14 release is scheduled for Monday 25 August 2020. Which means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Important reminder: if you add or change a translation in version 19.05, then you must also copy it to 19.11 and 20.05. Otherwise your work will be lost when upgrading to these next versions or the future ones. Happy translating, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Tue Aug 18 01:23:20 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 18 Aug 2020 09:23:20 +1000 Subject: [Koha-devel] Move .tt files out of "htdocs" and into separate "tt" or "templates" directory In-Reply-To: <20200817141552.2ee6248b@bletchley.towers.org.uk> References: <03f301d66afa$0ed13c10$2c73b430$@prosentient.com.au> <20200817141552.2ee6248b@bletchley.towers.org.uk> Message-ID: <01e801d674ed$65120800$2f361800$@prosentient.com.au> Hey MJ, I didn't realize that you were still in the Koha world. Nice to hear from you. I meant that Apache shouldn't serve the template files because doing so is not useful and - as far as I know - it is unintended. I think having unintended consequences is something to be avoided, even if the consequence is not a security risk (this time). As you note though, my real motivation is better/easier management of static assets. (With a longer view to what is described here for separately deploying static assets: https://docs.djangoproject.com/en/dev/howto/static-files/deployment/) Lately, I've been thinking how Koha owes some success from being geared towards very simple deployments (achieved by just following the instructions on the wiki), but how it should be friendly to more complex and modern deployments too. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of MJ Ray Sent: Monday, 17 August 2020 11:16 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Move .tt files out of "htdocs" and into separate "tt" or "templates" directory On Wed, 5 Aug 2020 17:28:47 +1000 wrote: > We should move all the .tt files out of the > /usr/share/koha/intranet/htdocs and /usr/share/koha/opac/htdocs > directories and put them somewhere private like /usr/share/koha/tt or > /usr/share/koha/templates. > > At the moment, Apache is serving these files to anyone who asks for > them, and it really shouldn't. Why shouldn't it? Do they contain anything sensitive that people couldn't discover by looking in the koha sources? > Having these files in the "htdocs" directories also makes it harder to > manage actual static assets that are served to Koha users. That seems like a far stronger reason not to do it. > I've opened a Bugzilla report for it: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26140 Cool. Thanks. Regards, -- MJR http://mjr.towers.org.uk/ Member of http://www.software.coop/ (but this email is my personal view only) _______________________________________________ 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Tue Aug 18 02:51:11 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 18 Aug 2020 10:51:11 +1000 Subject: [Koha-devel] Deploying Koha at scale In-Reply-To: References: <084501d63fc5$37f9bff0$a7ed3fd0$@prosentient.com.au> Message-ID: <01f501d674f9$aabcb1a0$003614e0$@prosentient.com.au> Hey Tomás, I remembered your email and I thought that I would check in. How’s work on koha-docker going? It looks interesting. It’s too bad the “koha-common” package name is already used, as it would be interesting to package just the core libraries and scripts to create a really minimal Koha image to use for the Z39.50, SIP, Indexer, etc. I look forward to a time when we don’t need Apache to do CGI scripts and just function as a reverse proxy and front end web server of static assets (or just the a web server of static assets and Traefik or something could be used as the reverse proxy). I think that I’m most intrigued with the cron service*, as I think that’s probably the hardest thing to containerize and scale well. I’ll have a look at running this up at some point! *(Kubernetes seems to have a neat approach to cronjobs https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/. Julia Evans talks about it at https://stripe.com/blog/operating-kubernetes. However, that would require a Kubernetes-first design, which makes no sense for Koha.) David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Tomás Sent: Friday, 12 June 2020 11:57 AM To: koha-devel Subject: [Koha-devel] Deploying Koha at scale Hi folks. Theke Solutions has started a project some time ago, sponsored by ByWater Solutions to generate the tools and pipelines to provide a reliable Docker implementation for deploying Koha in production environments. We have just finished the housekeeping a few days ago so we are not embarrassed by our commit messages and leftovers :-D and want to propose it for community adoption anytime soon. The project lives here for now: https://gitlab.com/thekesolutions/koha-docker What you will find there is a Docker image that can be used to run any of the different Koha services/pieces on separate containers, or all inside a single one. We aimed to target different deployment scenarios, from a small library running it on a desktop computer to a multi-cluster K8s setup. A helm chart is part of the roadmap. You will notice there are a couple issues to be addressed [1]. For instance, the shipped docker-compose.yml is outdated regarding the MySQL/MariaDB server and we definitely need more on the README. Thanks to ByWater for supporting this effort, and now that people are talking about this, let's start the conversation \o/ [1] https://gitlab.com/thekesolutions/koha-docker/-/issues El jue., 11 jun. 2020 a las 4:52, > escribió: Hi all, For a long time, I've been thinking about how Koha could scale better, and I'm wondering what other people are thinking about this topic. I think Mengu is probably the best expert on this topic that we have on Earth, so especially curious about his input. It's relatively easy to add more Apache web servers, more MySQL nodes, and more Elasticsearch nodes. but the same might not be said for other parts of Koha like the following: 1. Zebra a. In theory, you could load balance queries to a cluster of Zebra listeners b. But indexing updates to many Zebra databases could be tricky (I don't know if Zebra's database can support many readers). I suppose you could alter rebuild_zebra.pl to update multiple databases in a variety of different ways. I imagine Mengu could speak to this, as I recall him talking once about needing to do work to make Zebra scale? 2. I'm not familiar enough with the SIP server to say a. Off the top of my head, I think a TCP load balancer would be good enough here 3. Z3950 Responder? a. I'm not familiar with this daemon 4. What about cronjobs? Only 1 instance should execute the cronjobs. a. I suppose a person could disable cronjobs on all Koha nodes except for 1? It wouldn't be very robust in terms of availability but it would technically work most of the time. Any other thoughts? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From agustinmoyano at theke.io Tue Aug 18 17:50:52 2020 From: agustinmoyano at theke.io (Agustin Moyano) Date: Tue, 18 Aug 2020 12:50:52 -0300 Subject: [Koha-devel] Deploying Koha at scale In-Reply-To: <01f501d674f9$aabcb1a0$003614e0$@prosentient.com.au> References: <084501d63fc5$37f9bff0$a7ed3fd0$@prosentient.com.au> <01f501d674f9$aabcb1a0$003614e0$@prosentient.com.au> Message-ID: Hi David, we've got two separate projects. One is koha-docker (https://gitlab.com/thekesolutions/koha-docker) that has a "docker-compose" approach, and the second one is koha-helm-chart ( https://gitlab.com/thekesolutions/charts/koha-helm-chart) where we will implement the kubernetes cronjob approach. Please take a look at that one too. Regards On Mon, Aug 17, 2020 at 9:51 PM wrote: > Hey Tomás, > > > > I remembered your email and I thought that I would check in. How’s work on > koha-docker going? It looks interesting. > > > > It’s too bad the “koha-common” package name is already used, as it would > be interesting to package just the core libraries and scripts to create a > really minimal Koha image to use for the Z39.50, SIP, Indexer, etc. > > > > I look forward to a time when we don’t need Apache to do CGI scripts and > just function as a reverse proxy and front end web server of static assets > (or just the a web server of static assets and Traefik or something could > be used as the reverse proxy). > > > > I think that I’m most intrigued with the cron service*, as I think that’s > probably the hardest thing to containerize and scale well. > > > > I’ll have a look at running this up at some point! > > > > *(Kubernetes seems to have a neat approach to cronjobs > https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/. > Julia Evans talks about it at https://stripe.com/blog/operating-kubernetes. > However, that would require a Kubernetes-first design, which makes no sense > for Koha.) > > > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > *From:* Koha-devel *On > Behalf Of *Tomás > *Sent:* Friday, 12 June 2020 11:57 AM > *To:* koha-devel > *Subject:* [Koha-devel] Deploying Koha at scale > > > > > > Hi folks. > > > > Theke Solutions has started a project some time ago, sponsored by ByWater > Solutions to generate the tools and pipelines to provide a reliable Docker > implementation for deploying Koha in production environments. We have just > finished the housekeeping a few days ago so we are not embarrassed by our > commit messages and leftovers :-D and want to propose it for community > adoption anytime soon. > > > > The project lives here for now: > https://gitlab.com/thekesolutions/koha-docker > > > > What you will find there is a Docker image that can be used to run any of > the different Koha services/pieces on separate containers, or all inside a > single one. We aimed to target different deployment scenarios, from a small > library running it on a desktop computer to a multi-cluster K8s setup. A > helm chart is part of the roadmap. > > > > You will notice there are a couple issues to be addressed [1]. For > instance, the shipped docker-compose.yml is outdated regarding the > MySQL/MariaDB server and we definitely need more on the README. > > > > Thanks to ByWater for supporting this effort, and now that people are > talking about this, let's start the conversation \o/ > > > > [1] https://gitlab.com/thekesolutions/koha-docker/-/issues > > > > > > El jue., 11 jun. 2020 a las 4:52, escribió: > > Hi all, > > For a long time, I've been thinking about how Koha could scale better, and > I'm wondering what other people are thinking about this topic. I think > Mengu > is probably the best expert on this topic that we have on Earth, so > especially curious about his input. > > It's relatively easy to add more Apache web servers, more MySQL nodes, and > more Elasticsearch nodes. but the same might not be said for other parts of > Koha like the following: > > 1. Zebra > a. In theory, you could load balance queries to a cluster of Zebra > listeners > b. But indexing updates to many Zebra databases could be tricky (I > don't know if Zebra's database can support many readers). I suppose you > could alter rebuild_zebra.pl to update multiple databases in a variety of > different ways. I imagine Mengu could speak to this, as I recall him > talking > once about needing to do work to make Zebra scale? > > 2. I'm not familiar enough with the SIP server to say > a. Off the top of my head, I think a TCP load balancer would be > good > enough here > > 3. Z3950 Responder? > a. I'm not familiar with this daemon > > 4. What about cronjobs? Only 1 instance should execute the cronjobs. > a. I suppose a person could disable cronjobs on all Koha nodes > except for 1? It wouldn't be very robust in terms of availability but it > would technically work most of the time. > > Any other thoughts? > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Online: 02 8005 0595 > > > > > -- > > Tomás Cohen Arazi > > Theke Solutions (http://theke.io) > ✆ +54 9351 3513384 > GPG: B2F3C15F > _______________________________________________ > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Aug 19 03:58:09 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 19 Aug 2020 11:58:09 +1000 Subject: [Koha-devel] Deploying Koha at scale In-Reply-To: References: <084501d63fc5$37f9bff0$a7ed3fd0$@prosentient.com.au> <01f501d674f9$aabcb1a0$003614e0$@prosentient.com.au> Message-ID: <033c01d675cc$306ce770$9146b650$@prosentient.com.au> Thanks, Agustin. I haven’t played with Helm yet, but I recognize the Kubernetes manifests in there. It looks interesting. When will these 2 projects be ready for testing? With koha-docker, have you thought about using “secrets” rather than environmental variables for things like passwords? Reference https://docs.docker.com/compose/compose-file/#secrets. Secrets could be used for the Koha images too following a model like https://github.com/docker-library/mysql/blob/b0f81a33748561ae4e35a09895b2ad112ff89ba6/8.0/docker-entrypoint.sh. That could be useful if someone wanted to use Amazon ECS or something instead of docker-compose too actually. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Agustin Moyano Sent: Wednesday, 19 August 2020 1:51 AM To: dcook at prosentient.com.au Cc: Tomás ; koha-devel Subject: Re: [Koha-devel] Deploying Koha at scale Hi David, we've got two separate projects. One is koha-docker (https://gitlab.com/thekesolutions/koha-docker) that has a "docker-compose" approach, and the second one is koha-helm-chart (https://gitlab.com/thekesolutions/charts/koha-helm-chart) where we will implement the kubernetes cronjob approach. Please take a look at that one too. Regards On Mon, Aug 17, 2020 at 9:51 PM > wrote: Hey Tomás, I remembered your email and I thought that I would check in. How’s work on koha-docker going? It looks interesting. It’s too bad the “koha-common” package name is already used, as it would be interesting to package just the core libraries and scripts to create a really minimal Koha image to use for the Z39.50, SIP, Indexer, etc. I look forward to a time when we don’t need Apache to do CGI scripts and just function as a reverse proxy and front end web server of static assets (or just the a web server of static assets and Traefik or something could be used as the reverse proxy). I think that I’m most intrigued with the cron service*, as I think that’s probably the hardest thing to containerize and scale well. I’ll have a look at running this up at some point! *(Kubernetes seems to have a neat approach to cronjobs https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/. Julia Evans talks about it at https://stripe.com/blog/operating-kubernetes. However, that would require a Kubernetes-first design, which makes no sense for Koha.) David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel > On Behalf Of Tomás Sent: Friday, 12 June 2020 11:57 AM To: koha-devel > Subject: [Koha-devel] Deploying Koha at scale Hi folks. Theke Solutions has started a project some time ago, sponsored by ByWater Solutions to generate the tools and pipelines to provide a reliable Docker implementation for deploying Koha in production environments. We have just finished the housekeeping a few days ago so we are not embarrassed by our commit messages and leftovers :-D and want to propose it for community adoption anytime soon. The project lives here for now: https://gitlab.com/thekesolutions/koha-docker What you will find there is a Docker image that can be used to run any of the different Koha services/pieces on separate containers, or all inside a single one. We aimed to target different deployment scenarios, from a small library running it on a desktop computer to a multi-cluster K8s setup. A helm chart is part of the roadmap. You will notice there are a couple issues to be addressed [1]. For instance, the shipped docker-compose.yml is outdated regarding the MySQL/MariaDB server and we definitely need more on the README. Thanks to ByWater for supporting this effort, and now that people are talking about this, let's start the conversation \o/ [1] https://gitlab.com/thekesolutions/koha-docker/-/issues El jue., 11 jun. 2020 a las 4:52, > escribió: Hi all, For a long time, I've been thinking about how Koha could scale better, and I'm wondering what other people are thinking about this topic. I think Mengu is probably the best expert on this topic that we have on Earth, so especially curious about his input. It's relatively easy to add more Apache web servers, more MySQL nodes, and more Elasticsearch nodes. but the same might not be said for other parts of Koha like the following: 1. Zebra a. In theory, you could load balance queries to a cluster of Zebra listeners b. But indexing updates to many Zebra databases could be tricky (I don't know if Zebra's database can support many readers). I suppose you could alter rebuild_zebra.pl to update multiple databases in a variety of different ways. I imagine Mengu could speak to this, as I recall him talking once about needing to do work to make Zebra scale? 2. I'm not familiar enough with the SIP server to say a. Off the top of my head, I think a TCP load balancer would be good enough here 3. Z3950 Responder? a. I'm not familiar with this daemon 4. What about cronjobs? Only 1 instance should execute the cronjobs. a. I suppose a person could disable cronjobs on all Koha nodes except for 1? It wouldn't be very robust in terms of availability but it would technically work most of the time. Any other thoughts? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F _______________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Wed Aug 26 09:41:26 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 26 Aug 2020 17:41:26 +1000 Subject: [Koha-devel] Self-checkout uses issuing rules rather than renewal rules for renewals Message-ID: <035201d67b7c$4d980d60$e8c82820$@prosentient.com.au> I had a librarian report that they got stuck in a loop when trying to renew overdue items via the self-checkout. I've written a patch at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26301, and I'm keen to get testers. The self-checkout isn't very straightforward, so I hope others can make sure I didn't miss anything. Doing checkouts and renewals looks good to me so far though. Cheers, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dcook at prosentient.com.au Thu Aug 27 09:00:25 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 27 Aug 2020 17:00:25 +1000 Subject: [Koha-devel] Add warning in IE that Koha does not support IE Message-ID: <04f501d67c3f$bd8210d0$38863270$@prosentient.com.au> Hi all, I don't know about you, but I have received a lot of calls about Koha not working in IE 11. Now I think that it is wise that we no longer support IE 11, especially since Microsoft itself is dropping support for it in November 2020, but I think warning people is not a bad idea. I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26305 to do just that. Keen to get feedback / signoffs. Cheers, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: