From stephane.delaune at biblibre.com Thu Oct 3 12:22:35 2019 From: stephane.delaune at biblibre.com (=?UTF-8?Q?St=c3=a9phane_Delaune?=) Date: Thu, 3 Oct 2019 12:22:35 +0200 Subject: [Koha-devel] update MARC::Transform in debian.koha-community.org Message-ID: Hello, I'm Stéphane Delaune (aka reiveune) from BibLibre I am the developer of the Perl module MARC::Transform ( https://metacpan.org/pod/MARC::Transform ), this module is in version 0.003008 since april but, in debian.koha-community.org, the version is only 0.003006 that is 5 years old (2 versions late, including a bugfix) I would like to know if someone is able to update this package in debian.koha-community.org (and in https://packages.qa.debian.org/libm/libmarc-transform-perl.html on which the version is 0.003007) thank you in advance Stéphane Delaune From paul.poulain at biblibre.com Fri Oct 4 14:31:46 2019 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 4 Oct 2019 14:31:46 +0200 Subject: [Koha-devel] Hackfest meeting about Mana-kb Message-ID: Hello all, We had a quite productive meeting regarding mana-kb during the hackfest. We had many ideas regarding improvements / new features that could be added, I've created a bugzilla entry for each idea. Below is a summary of our work reminder : and "object" is something that is shared through mana. For now, subscription patterns and reports can be shared. * there's a web interface (ui.mana-kb) to look at data, and delete old/outdated. The idea is to curate data regularly. Anyone can apply to become a curator of the data in mana-kb. New features idea : o add a button "apply as curator" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23738 o prepare some SQL queries that could show librarians contributing a lot, and proposing them to join the list of curators https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23739 o Let curators flag a content (3 values : non-flagged / hide this object, to be discussed for deletion / 'star' this object, it has a high quality/value) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23740 * Sharing reports guidelines https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23741 o When you share a report, Koha could check if there's a runtime value to set (<>). If there's none, add a confirmation checkbox, most useful reports need a runtime parameter. o Add a hint : "do not share a report with hardcoded value related to your own data" that is displayed when the librarian want to share a report * Languages checks are made on the full language code (fr_FR). We need only the first 2. Thus, reports with language fr_FR are displayed also for our canadian-Quebec friends (same thing for en_EN, en_US, en_NZ, of course) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23742 * In the admin/share_content.pl page => show if a token has not been validated yet https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23743 * In the result lists (for object (reports, ...) searching, add a column with the language of submission, that can be filtered/sorted https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23744 * in ui.mana-kb : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23745 o hide the token column, a curator does not need to know the token of a librarian o add a feature 'resend token' => resend the validation email to the librarian * In Koha : check that the associated email is an email, to avoid unvalidable tokens https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23746 * replace a local Koha object by a mana-kb one: currently, it's not possible to modify a local object with one coming from Mana-kb. Add this feature, 2 sub-features: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23747 o if the local object comes from Mana, have a message "hey, the mana object has been updated, clic here to update your local one" o if the local object is 'home-made', add a button "update from mana-kb" that let the librarian search in mana, and update his local data. * "golden mana-kb contributor": we expect to have some librarians contributing very efficiently and frequently. Those librarians should be able to update existing mana objects. The golden mana-kb contributor is given by curators, coopt/consensus. The golden contributor status can be given for reports and for subscriptions, separately. -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From agustinmoyano at theke.io Fri Oct 4 18:22:12 2019 From: agustinmoyano at theke.io (Agustin Moyano) Date: Fri, 4 Oct 2019 13:22:12 -0300 Subject: [Koha-devel] API use in intranet and OPAC Message-ID: Hello everyone, I'll introduce myself for those of you who didn't "git blame" me... I'm the one who introduced that huge, nasty, blocking bug, that didn't ley you place a simple hold on intranet. I'm glad to announce that patch is on the way, and passed QA. This was one of the first steps (if not the first) of using the API in intranet. A really clumpsy step, I give you that, but as they saying says.. "That's one small step for [a] man, one giant leap for the API", but in my case, if I've been Neil Armstrong, I've probably tripped as soon as I got out of the module, get my helmet all scratched and filled with moon dust, and instead of a nice clean footprint, there would have been a fuzzy figure resembling a space suit trying to get up. Marcel de Rooy, the generous soul who passedQA the solution patch, complained (and he was absolutely right) about a couple of things: 1. That there was no comunication about this in dev channel before implementing. It's too late for discusing before implementing, but I would really like to know your opinion post implementation. 2. OPAC and Intranet now use diferent methods to place holds.. one uses the API, the other uses a POST to a .pl file. I think it best to move OPAC to use the API, but this time I'm going to hear you first. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Fri Oct 4 18:29:46 2019 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 4 Oct 2019 12:29:46 -0400 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: Message-ID: > I think it best to move OPAC to use the API, but this time I'm going to hear you first. Would this make the holds process dependent on JavaScript? Owen -- Web Developer Athens County Public Libraries https://www.myacpl.org From M.de.Rooy at rijksmuseum.nl Mon Oct 7 11:44:35 2019 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 7 Oct 2019 09:44:35 +0000 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: Message-ID: We found a few other intranet places as well (thx Katrin). The first comes from bug 8030, august 2016. root at master:/usr/share/koha/koha-tmpl/intranet-tmpl/prog# git grep -l "/api/v1/" [Bug 15496 12-04-19] en/modules/cataloguing/moveitem.tt [Bug 23710 01-10-19] en/modules/reserve/request.tt [FIRST REPORT Bug 8030 19-08-16] js/holds.js [Bug 18589, but originated from bug 7317 03-02-17] js/ill-list-table.js [Bug 11897 01-10-2018] js/pages/stockrotation.js root at master:/usr/share/koha/koha-tmpl/opac-tmpl/bootstrap# git grep -l "/api/v1/" [FIRST OPAC Bug 23623 16-09-2019] en/modules/opac-memberentry.tt ________________________________ ​Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl ​ ​Nu te zien: ​​​Louise Bourgeois in de Rijksmuseumtuinen ​Operatie Nachtwacht ​ ​Verwacht: ​Rembrandt-Velázquez. Nederlandse & Spaanse meesters ​ ​ ​T/m 18 jaar gratis Please think before you print Van: Koha-devel namens Agustin Moyano Verzonden: vrijdag 4 oktober 2019 18:22 Aan: Koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] API use in intranet and OPAC Hello everyone, I'll introduce myself for those of you who didn't "git blame" me... I'm the one who introduced that huge, nasty, blocking bug, that didn't ley you place a simple hold on intranet. I'm glad to announce that patch is on the way, and passed QA. This was one of the first steps (if not the first) of using the API in intranet. A really clumpsy step, I give you that, but as they saying says.. "That's one small step for [a] man, one giant leap for the API", but in my case, if I've been Neil Armstrong, I've probably tripped as soon as I got out of the module, get my helmet all scratched and filled with moon dust, and instead of a nice clean footprint, there would have been a fuzzy figure resembling a space suit trying to get up. Marcel de Rooy, the generous soul who passedQA the solution patch, complained (and he was absolutely right) about a couple of things: 1. That there was no comunication about this in dev channel before implementing. It's too late for discusing before implementing, but I would really like to know your opinion post implementation. 2. OPAC and Intranet now use diferent methods to place holds.. one uses the API, the other uses a POST to a .pl file. I think it best to move OPAC to use the API, but this time I'm going to hear you first. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image775975.png Type: image/png Size: 2974 bytes Desc: image775975.png URL: From kyle.m.hall at gmail.com Mon Oct 7 12:16:46 2019 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Mon, 7 Oct 2019 06:16:46 -0400 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: Message-ID: I'm going to go out on a limb and say it will indeed require javascript. There are a number of OPAC features ( though non-essential ) that don't function without javascript. Is this still a requirement for the OPAC? Kyle --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 4, 2019 at 12:30 PM Owen Leonard wrote: > > I think it best to move OPAC to use the API, but this time I'm going to > hear you first. > > Would this make the holds process dependent on JavaScript? > > Owen > > -- > Web Developer > Athens County Public Libraries > 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 -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon Oct 7 12:20:02 2019 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 7 Oct 2019 12:20:02 +0200 Subject: [Koha-devel] Koha, centOS, Apache, starman => random timeout ! In-Reply-To: <866232dc-c626-fc18-ab6e-409496ed08d3@biblibre.com> References: <866232dc-c626-fc18-ab6e-409496ed08d3@biblibre.com> Message-ID: <02bb9e52-36cc-b065-f3d6-28a2b1c77791@biblibre.com> for the record: The mariaDB was on a separate server. We re-internalized the DB in the Koha VM, and no more problem ! So the problem is not centOS specific probably. Le 18/07/2019 à 11:37, Paul Poulain a écrit : > > Hello, > > We have a library running Koha (17.11) on his own centOS (virtual) > server, with Apache as webserver. > > Everything is working smoothly, except that, from time to time (about > once a day), it's not working anymore, any page returns: "Proxy error, > Error reading from remote server" > > The logs shows nothing except a strange: > >  [Wed Jul 10 17:17:35.732798 2019] [proxy_http:error] [pid 322] > (70007)The timeout specified has expired: [client 1.2.3.4:32988] > AH01102: error reading status line from remote server localhost:5000, > referer: > https://xxx.xxx.xxx.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=78504&searchid=scs_1562770062842 > > [Wed Jul 10 17:17:35.732861 2019] [proxy:error] [pid 322] [client > 1.2.3.4:32988] AH00898: Error reading from remote server returned by > /cgi-bin/koha/catalogue/search.pl, referer: > https://xxx.xxx.xxx.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=78504&searchid=scs_1562770062842 > > > What is stranger : after a few minutes, without any action on the > server, everything is back, and working well. > > did anyone face such a problem ? any idea welcomed ! > -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Oct 7 13:15:39 2019 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 7 Oct 2019 11:15:39 +0000 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: , Message-ID: Yeah I guess we reached the point that we just need javascript in OPAC ? ​Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl ​ ​Nu te zien: ​​​Louise Bourgeois in de Rijksmuseumtuinen ​Operatie Nachtwacht ​ ​Verwacht: ​Rembrandt-Velázquez. Nederlandse & Spaanse meesters ​ ​ ​T/m 18 jaar gratis Please think before you print -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001621.png Type: image/png Size: 2974 bytes Desc: image001621.png URL: From kyle.m.hall at gmail.com Mon Oct 7 13:28:40 2019 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Mon, 7 Oct 2019 07:28:40 -0400 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: Message-ID: I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy wrote: > Yeah I guess we reached the point that we just need javascript in OPAC ? > > ​ > > [image: http://www.rijksmuseum.nl] > > ​Museumstraat 1 > Postbus 74888 > 1070 DN Amsterdam > *Rijksmuseum.nl* > ​ > ​Nu te zien: > ​​*​Louise Bourgeois in de Rijksmuseumtuinen* > > ​*Operatie Nachtwacht* > ​ > ​Verwacht: > ​*Rembrandt-Velázquez. Nederlandse & Spaanse meesters* > > ​ > ​ > ​T/m 18 jaar gratis > > Please think before you print > _______________________________________________ > 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: image001621.png Type: image/png Size: 2974 bytes Desc: not available URL: From tomascohen at gmail.com Mon Oct 7 21:32:04 2019 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 7 Oct 2019 16:32:04 -0300 Subject: [Koha-devel] Mini roadmap for the API Message-ID: Hi, with the HAL introduction in mind I plan to (at least) provide a sample implementation of the following: - Add a 'to_api' method to Koha::Object and Koha::Objects that can be overloaded if needed (trivial, WIP 23770) - Pick a sample endpoint (probably /cities) and make sure the implementation keeps the current behaviour (trivial, besides the boring tests) - Move the existing controllers into using this (trivial) - Implement in some sample class, to be determined, ->to_api_hal. And make the endpoint that uses it, Accept: application/hal+json and return this new data structure. So if JSON is requested, the current behaviour is kept. Otherwise, the HAL representation will be returned. Things to think about and which we will be able to play with: - How to determine the depth of the embedding? (HAL has that ability) - Should we specify which FK to follow and embed on the query? how would that query look like? Thanks for your time :-D -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Mon Oct 7 22:31:26 2019 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Mon, 7 Oct 2019 22:31:26 +0200 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: Message-ID: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote: > I think it's pretty practical at this point in time to agree that if > we are to continue making a modern web app, we need to require javascript. > --- > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > > > On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy > > wrote: > > Yeah I guess we reached the point that we just need javascript in > OPAC ? > > ​ > > > http://www.rijksmuseum.nl > > > ​Museumstraat 1 > Postbus 74888 > 1070 DN Amsterdam > *Rijksmuseum.nl* > ​ > ​Nu te zien: > ​​*​Louise Bourgeois in de Rijksmuseumtuinen* > > ​*Operatie Nachtwacht* > ​ > ​Verwacht: > ​*Rembrandt-Velázquez. Nederlandse & Spaanse meesters* > > ​ > ​ > ​T/m 18 jaar gratis > > Please think before you print > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001621.png Type: image/png Size: 2974 bytes Desc: not available URL: From dcook at prosentient.com.au Tue Oct 8 01:53:59 2019 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Oct 2019 10:53:59 +1100 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> Message-ID: <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs. I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic. If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility. Just my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Koha-devel On Behalf Of Katrin Fischer Sent: Tuesday, 8 October 2019 7:31 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] API use in intranet and OPAC If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote: I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy > wrote: Yeah I guess we reached the point that we just need javascript in OPAC ? ​ ​Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl ​ ​Nu te zien: ​​ ​Louise Bourgeois in de Rijksmuseumtuinen ​ Operatie Nachtwacht ​ ​Verwacht: ​ Rembrandt-Velázquez. Nederlandse & Spaanse meesters ​ ​ ​T/m 18 jaar gratis Please think before you print _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From arthur.suzuki at biblibre.com Tue Oct 8 02:31:36 2019 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Tue, 08 Oct 2019 02:31:36 +0200 Subject: [Koha-devel] Mini roadmap for the API In-Reply-To: References: Message-ID: <958E0305-A051-43BB-925E-966656870998@biblibre.com> Hi Tomas, I'd say both parameters shall be sent in the body of the request (just like when sending a new password using the API). In that case you could have a parameter called "depth" and a parameter called "relations" with a json array of keys? This way the url called doesn't change much and even a quite big relations list can be provided. HAL looks great by the way, i just discover this! Le 7 octobre 2019 21:32:04 GMT+02:00, Tomas Cohen Arazi a écrit : >Hi, with the HAL introduction in mind I plan to (at least) provide a >sample >implementation of the following: > >- Add a 'to_api' method to Koha::Object and Koha::Objects that can be >overloaded if needed (trivial, WIP 23770) >- Pick a sample endpoint (probably /cities) and make sure the >implementation keeps the current behaviour (trivial, besides the boring >tests) >- Move the existing controllers into using this (trivial) >- Implement in some sample class, to be determined, ->to_api_hal. And >make >the endpoint that uses it, Accept: application/hal+json and return this >new >data structure. So if JSON is requested, the current behaviour is kept. >Otherwise, the HAL representation will be returned. > >Things to think about and which we will be able to play with: >- How to determine the depth of the embedding? (HAL has that ability) >- Should we specify which FK to follow and embed on the query? how >would >that query look like? > >Thanks for your time :-D > >-- >Tomás Cohen Arazi >Theke Solutions (http://theke.io) >✆ +54 9351 3513384 >GPG: B2F3C15F Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.suzuki at biblibre.com Tue Oct 8 02:17:26 2019 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Tue, 08 Oct 2019 02:17:26 +0200 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> Message-ID: <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> One but not least issue with JavaScript, how do we test this? I mean it's easy to test the API itself, making requests to it and monitoring the change in the koha db or mock objects. It's also easy to check if the Intranet or Opac page returned by the server contains some strings in the html code (I guess, didn't try though). How do we execute the Javascript in the test and verify it has the expected behavior? Overall I have to say I'm very happy with this change (using more API) though, since it will raise interest for this further and can bring Koha to a whole new level within libraries app, Koha being at the core of other third parties apps to interact with (not to mention them: Coral ERMS and Bokeh Library Frontend). \o/ Le 8 octobre 2019 01:53:59 GMT+02:00, dcook at prosentient.com.au a écrit : >I agree with Katrin. I think we need to be careful to think as >developers in the open source GLAM space rather than the less >accountable corporate space. While I’m a few years out of date when it >comes to accessibility, I do still have some friends who are experts in >that area and could get their opinion on the matter. From what I >remember, Javascript != accessible. I think it was because >screenreaders, at least historically, didn’t render the Javascript and >that caused the lack of functionality for people with accessibility >needs. > > > >I’d also add that we can use the API without using Javascript. We could >build a lightweight controller which does the API call on the server >backend rather than from the client browser, so the user could POST to >a CGI .pl script (or a PSGI route), and the API handles all the real >business logic. > > > >If we wanted to be modern, we could use Javascript to call the API, but >fail gracefully by POSTing the form instead if Javascript turns off. I >know that would be a lot more work, but that could way we could keep >the modernity while also maintaining accessibility. > > > >Just my 2 cents. > > > >David Cook > >Systems Librarian > >Prosentient Systems > >72/330 Wattle St > >Ultimo, NSW 2007 > >Australia > > > >Office: 02 9212 0899 > >Direct: 02 8005 0595 > > > >From: Koha-devel On >Behalf Of Katrin Fischer >Sent: Tuesday, 8 October 2019 7:31 AM >To: koha-devel at lists.koha-community.org >Subject: Re: [Koha-devel] API use in intranet and OPAC > > > >If we decide to require JavaScript for the OPAC we should be careful to >do it in a way that is accessible. Accessibility can even be a legal >requirement in some countries for websites of public institutions like >libraries. > >Katrin > >On 07.10.19 13:28, Kyle Hall wrote: > >I think it's pretty practical at this point in time to agree that if we >are to continue making a modern web app, we need to require javascript. > > >--- > >http://www.kylehall.info >ByWater Solutions ( http://bywatersolutions.com ) >Meadville Public Library ( http://www.meadvillelibrary.org ) >Crawford County Federated Library System ( http://www.ccfls.org ) > > > > > >On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy > wrote: > >Yeah I guess we reached the point that we just need javascript in OPAC >? > > > > > ​ > > > > > > > > > > > >​Museumstraat 1 >Postbus 74888 >1070 DN Amsterdam > Rijksmuseum.nl >​ >​Nu te zien: >​​ > >​Louise Bourgeois in de Rijksmuseumtuinen >​ Operatie Nachtwacht >​ >​Verwacht: >​ > >Rembrandt-Velázquez. Nederlandse & Spaanse meesters >​ >​ >​T/m 18 jaar gratis > > Please think before you print > >_______________________________________________ >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/ Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Oct 8 02:47:03 2019 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Oct 2019 11:47:03 +1100 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> Message-ID: <059001d57d71$e6bd74d0$b4385e70$@prosentient.com.au> Testing is always an interesting one. I’d say unit tests for the API functions and unit tests for the controller functions. You could mock the API for the latter. For integration tests, you could use selenium to test the integration between the two. Alternatively, manual integration tests. Personally, I’m hugely in favour of using the API for all business logic for OPAC functionality. The Koha OPAC could be a reference implementation and out-of-the-box solution, but then third party apps and library websites could opt out of using the Koha OPAC and instead just integrate with the API directly. I think a lot of my clients would actually prefer to integrate a Koha OPAC API into their own websites rather than using the Koha OPAC website. I suppose one downside could be the Koha OPAC website could become neglected, if everyone was just maintaining their own user interfaces. But I imagine a lot of people would still want to use the Koha OPAC website too. (After all, integrating with third-party APIs can be very challenging too!) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Arthur Suzuki Sent: Tuesday, 8 October 2019 11:17 AM To: koha-devel at lists.koha-community.org; dcook at prosentient.com.au; 'Katrin Fischer' Subject: Re: [Koha-devel] API use in intranet and OPAC One but not least issue with JavaScript, how do we test this? I mean it's easy to test the API itself, making requests to it and monitoring the change in the koha db or mock objects. It's also easy to check if the Intranet or Opac page returned by the server contains some strings in the html code (I guess, didn't try though). How do we execute the Javascript in the test and verify it has the expected behavior? Overall I have to say I'm very happy with this change (using more API) though, since it will raise interest for this further and can bring Koha to a whole new level within libraries app, Koha being at the core of other third parties apps to interact with (not to mention them: Coral ERMS and Bokeh Library Frontend). \o/ Le 8 octobre 2019 01:53:59 GMT+02:00, dcook at prosentient.com.au a écrit : I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs. I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic. If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility. Just my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Koha-devel > On Behalf Of Katrin Fischer Sent: Tuesday, 8 October 2019 7:31 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] API use in intranet and OPAC If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote: I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy > wrote: Yeah I guess we reached the point that we just need javascript in OPAC ? ​ ​Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl ​ ​Nu te zien: ​​ ​Louise Bourgeois in de Rijksmuseumtuinen ​ Operatie Nachtwacht ​ ​Verwacht: ​ Rembrandt-Velázquez. Nederlandse & Spaanse meesters ​ ​ ​T/m 18 jaar gratis Please think before you print _______________________________________________ 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/ Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 -------------- 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 Oct 8 03:34:19 2019 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Oct 2019 12:34:19 +1100 Subject: [Koha-devel] Turn on DEBUG for Koha Plack instance Message-ID: <059c01d57d78$814555d0$83d00170$@prosentient.com.au> Hi all, How do you (temporarily) turn on DEBUG mode for Koha Plack? I looked inside and out and nothing I tried seemed to work? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 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 indradg at l2c2.co.in Tue Oct 8 10:04:44 2019 From: indradg at l2c2.co.in (Indranil Das Gupta) Date: Tue, 8 Oct 2019 13:34:44 +0530 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: <059001d57d71$e6bd74d0$b4385e70$@prosentient.com.au> References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> <059001d57d71$e6bd74d0$b4385e70$@prosentient.com.au> Message-ID: Hi, On Tue, 8 Oct 2019 at 06:17, wrote: > I suppose one downside could be the Koha OPAC website could become > neglected, if everyone was just maintaining their own user interfaces. But > I imagine a lot of people would still want to use the Koha OPAC website too. > (After all, integrating with third-party APIs can be very challenging too!) I agree. For library professionals without programming skills or access to qualified IT support, who are bootstrapping their library automation using Koha, the OPAC is central key feature. I see the OPAC continuing to remain important to that user segment for at least the next 5 years. Cheers Indranil Das Gupta L2C2 Technologies From arthur.suzuki at biblibre.com Tue Oct 8 23:35:53 2019 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Tue, 08 Oct 2019 23:35:53 +0200 Subject: [Koha-devel] Koha-testing-docker and Mana In-Reply-To: References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> <059001d57d71$e6bd74d0$b4385e70$@prosentient.com.au> Message-ID: Hi, Just wondering if there is any way to define the Mana Url in some environment variable when setting up the koha-testing-docker. Wish to do some testing on those solutions and wonders if I could do it on a local and easily reproductible environment. Looked around, couldn't find. Thanks in advance for your help :) Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 From tomascohen at gmail.com Wed Oct 9 04:00:13 2019 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 8 Oct 2019 23:00:13 -0300 Subject: [Koha-devel] Koha-testing-docker and Mana In-Reply-To: References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> <059001d57d71$e6bd74d0$b4385e70$@prosentient.com.au> Message-ID: File an issue on gitlab with the proposed behavior! El mar., 8 de octubre de 2019 18:35, Arthur Suzuki < arthur.suzuki at biblibre.com> escribió: > Hi, > Just wondering if there is any way to define the Mana Url in some > environment variable when setting up the koha-testing-docker. > Wish to do some testing on those solutions and wonders if I could do it on > a local and easily reproductible environment. > Looked around, couldn't find. > Thanks in advance for your help :) > Arthur Suzuki > Développeur Support chez BibLibre > +33 6 37 94 13 53 > _______________________________________________ > 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 arthur.suzuki at biblibre.com Wed Oct 9 09:57:02 2019 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Wed, 09 Oct 2019 09:57:02 +0200 Subject: [Koha-devel] Koha-testing-docker and Mana In-Reply-To: References: <3ec3b7af-d0a3-4241-ad68-b603f2c77dd5@web.de> <057801d57d6a$7d3ad270$77b07750$@prosentient.com.au> <2F8D1A74-7182-4709-AF3A-F44F2A20EAA4@biblibre.com> <059001d57d71$e6bd74d0$b4385e70$@prosentient.com.au> Message-ID: <194F6DE0-FE88-4C3B-A48A-F7CAD9680381@biblibre.com> Ok i'd rather try to submit a merge request then ;) Le 9 octobre 2019 04:00:13 GMT+02:00, Tomas Cohen Arazi a écrit : >File an issue on gitlab with the proposed behavior! > >El mar., 8 de octubre de 2019 18:35, Arthur Suzuki < >arthur.suzuki at biblibre.com> escribió: > >> Hi, >> Just wondering if there is any way to define the Mana Url in some >> environment variable when setting up the koha-testing-docker. >> Wish to do some testing on those solutions and wonders if I could do >it on >> a local and easily reproductible environment. >> Looked around, couldn't find. >> Thanks in advance for your help :) >> Arthur Suzuki >> Développeur Support chez BibLibre >> +33 6 37 94 13 53 >> _______________________________________________ >> 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/ >> Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Mon Oct 14 09:24:08 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Mon, 14 Oct 2019 09:24:08 +0200 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: References: Message-ID: <3180d176-73b2-4316-1bf3-2c576e716e6d@biblibre.com> +1 for me. I'm sure modern web-browsers can provide a good accessiblity even with JS/Ajax. Le 07/10/2019 à 13:28, Kyle Hall a écrit : > I think it's pretty practical at this point in time to agree that if we > are to continue making a modern web app, we need to require javascript. > --- > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > > > On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy > wrote: > > Yeah I guess we reached the point that we just need javascript in OPAC ? > > ​ > > > http://www.rijksmuseum.nl > > > ​Museumstraat 1 > Postbus 74888 > 1070 DN Amsterdam > *Rijksmuseum.nl* > ​ > ​Nu te zien: > ​​*​Louise Bourgeois in de Rijksmuseumtuinen* > > ​*Operatie Nachtwacht* > ​ > ​Verwacht: > ​*Rembrandt-Velázquez. Nederlandse & Spaanse meesters* > > ​ > ​ > ​T/m 18 jaar gratis > > Please think before you print > > _______________________________________________ > 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/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer From jonathan.druart at bugs.koha-community.org Mon Oct 14 10:01:13 2019 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 14 Oct 2019 10:01:13 +0200 Subject: [Koha-devel] Removing data from hea.koha-community.org In-Reply-To: <06de01d56132$9a376b80$cea64280$@prosentient.com.au> References: <06de01d56132$9a376b80$cea64280$@prosentient.com.au> Message-ID: Hi David, So far we do not. You can contact me to remove specific entries. A couple of years ago I manually removed the "too old" entries (no update in the last X months). You should open an enhancement request ticket :) Cheers, Jonathan Le lun. 2 sept. 2019 à 04:03, a écrit : > > Hi all, > > > > Do we have any process for removing data from hea.koha-community.org? > > > > For instance, say that a library permanently closes, or just no longer wants to be listed? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 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 jonathan.druart at bugs.koha-community.org Mon Oct 14 10:50:50 2019 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 14 Oct 2019 10:50:50 +0200 Subject: [Koha-devel] Duplicated holds notices In-Reply-To: References: Message-ID: So I guess you also see 2 entries in the 'reserve' table, as well as 2 HOLDS.CREATE logs? Note that I can easily add 2 holds from request.pl, double-clicking the submit button. Le mer. 4 sept. 2019 à 20:33, Nick Clemens a écrit : > Yes, we see two post requests, the timestamps are identical > > On Sun, Sep 1, 2019 at 11:48 AM Jonathan Druart < > jonathan.druart at bugs.koha-community.org> wrote: > >> Hi Nick, >> >> You are talking about HOLDPLACED, right? >> What about the timestamps, are they identical? Do you see 2 queries in >> the webserver logs? >> >> Cheers, >> Jonathan >> >> Le mer. 21 août 2019 à 15:01, Nick Clemens a >> écrit : >> >>> Hi All, >>> >>> We have been getting several reports of duplicated holds notices on a >>> few systems. >>> >>> We cannot find any issues in the code that would duplciate this, there >>> are not duplicated transports or anything in the data we can find. >>> >>> We have noticed that some of the modals have a submit button, and then >>> js to submit the form, however, Kyle attempted to add >>> 'preventDoubleFormSubmit()' to the page and that has not helped >>> >>> $(document).ready(function() { if (window.location.href.indexOf("circ/ >>> returns.pl") > -1) { $('form').preventDoubleFormSubmit(); } }); >>> >>> Has anyone else experienced this? >>> >>> -Nick >>> >>> -- >>> Nick Clemens >>> ByWater Solutions >>> bywatersolutions.com >>> Phone: (888) 900-8944 >>> Pronouns: (he/him/his) >>> Timezone: Eastern >>> >>> _______________________________________________ >>> 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/ >>> >> > > -- > Nick Clemens > ByWater Solutions > bywatersolutions.com > Phone: (888) 900-8944 > Pronouns: (he/him/his) > Timezone: Eastern > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Oct 15 03:24:33 2019 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 15 Oct 2019 12:24:33 +1100 Subject: [Koha-devel] API use in intranet and OPAC In-Reply-To: <3180d176-73b2-4316-1bf3-2c576e716e6d@biblibre.com> References: <3180d176-73b2-4316-1bf3-2c576e716e6d@biblibre.com> Message-ID: <01f101d582f7$4d019520$e704bf60$@prosentient.com.au> This certainly makes me wonder. In Australia, JAWS appears to be the recommended Microsoft Windows screen reader (https://www.visionaustralia.org/information/adaptive-technology/using-technology/computer-screen-readers), and the Wikipedia entry says that Internet Explorer is the recommended browser for JAWS (https://en.wikipedia.org/wiki/JAWS_(screen_reader)). After some searching around, it seems that there are a mix of Accessibility APIs out there. The free screen reader NVDA (https://www.nvaccess.org/download/) is said to work best with Firefox (and it looks like Firefox and Chrome may use the same API protocols so maybe it works well in Chrome too). I haven't noticed anything about specific browser versions at this point. I know we use ARIA attributes a bit... mostly through Bootstrap boilerplate I think: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA After reading https://www.levelaccess.com/how-browsers-interact-with-screen-readers-and-where-aria-fits-in-the-mix/, I think it would be naïve to think that we can make Koha totally accessible without more specialized knowledge and resources. Plus, most modern web apps out there that people are interacting with are using Javascript. (Although they might be implemented in a way that is conducive to screen reader use.) I think a number of Koha developers use Mac, which I think comes with VoiceOver. They could see how well that fares with Koha. I had a classmate from Atlassian build a completely Javascript driven app and he leveraged VoiceOver to read the screen (it was a flashcard app for learning Chinese). So perhaps modern technology is sufficiently advanced at this point not to have to worry too much. I'm not saying that we should mandate accessibility at this point as that could be a prohibitive mandate for contributions, but it might be interesting to try out some tools to see how we're doing and if there is little things we could do to try to do the best we can for people with accessibility needs. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Fridolin SOMERS Sent: Monday, 14 October 2019 6:24 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] API use in intranet and OPAC +1 for me. I'm sure modern web-browsers can provide a good accessiblity even with JS/Ajax. Le 07/10/2019 à 13:28, Kyle Hall a écrit : > I think it's pretty practical at this point in time to agree that if > we are to continue making a modern web app, we need to require javascript. > --- > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) Meadville Public > Library ( http://www.meadvillelibrary.org ) Crawford County Federated > Library System ( http://www.ccfls.org ) > > > On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy > > wrote: > > Yeah I guess we reached the point that we just need javascript in OPAC ? > > ​ > > > http://www.rijksmuseum.nl > > > ​Museumstraat 1 > Postbus 74888 > 1070 DN Amsterdam > *Rijksmuseum.nl* > ​ > ​Nu te zien: > ​​*​Louise Bourgeois in de Rijksmuseumtuinen* > > ​*Operatie Nachtwacht* > ​ > ​Verwacht: > ​*Rembrandt-Velázquez. Nederlandse & Spaanse meesters* > > ​ > ​ > ​T/m 18 jaar gratis > > Please think before you print > > _______________________________________________ > 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/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer _______________________________________________ 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 oleonard at myacpl.org Tue Oct 15 15:01:26 2019 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 15 Oct 2019 09:01:26 -0400 Subject: [Koha-devel] Let's talk about the future of Bug 15522 Message-ID: Bug 15522, "New interface for revamped circulation rules" (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522) has been in limbo for a long time. It's a big change that relies on a patch that makes a big change: Bug 18936 - Convert issuingrules fields to circulation_rules (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18936). 18936 is particularly intimidating because of the extent of the changes. It's too much for one person to test thoroughly enough. If we agree that these bugs are worthy of moving forward, let's plan a coordinated effort to get them tested. I think it's probably too late for 11.19, but perhaps we could make a plan for the next release? A GBSD for just Bug 18936? Thanks, -- Owen -- Web Developer Athens County Public Libraries https://www.myacpl.org From jonathan.druart at bugs.koha-community.org Tue Oct 15 15:08:58 2019 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 15 Oct 2019 15:08:58 +0200 Subject: [Koha-devel] Let's talk about the future of Bug 15522 In-Reply-To: References: Message-ID: If we have a GBSD and a group focussing on it, I would suggest to work directly on 15522. Le mar. 15 oct. 2019 à 15:01, Owen Leonard a écrit : > > Bug 15522, "New interface for revamped circulation rules" > (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522) has > been in limbo for a long time. It's a big change that relies on a > patch that makes a big change: Bug 18936 - Convert issuingrules fields > to circulation_rules > (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18936). > > 18936 is particularly intimidating because of the extent of the > changes. It's too much for one person to test thoroughly enough. > > If we agree that these bugs are worthy of moving forward, let's plan a > coordinated effort to get them tested. I think it's probably too late > for 11.19, but perhaps we could make a plan for the next release? A > GBSD for just Bug 18936? > > Thanks, > > -- Owen > > -- > Web Developer > Athens County Public Libraries > 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/ From tomascohen at gmail.com Tue Oct 15 15:30:56 2019 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 15 Oct 2019 10:30:56 -0300 Subject: [Koha-devel] Let's talk about the future of Bug 15522 In-Reply-To: References: Message-ID: Let's have a GBSD next friday! El mar., 15 oct. 2019 a las 10:09, Jonathan Druart (< jonathan.druart at bugs.koha-community.org>) escribió: > If we have a GBSD and a group focussing on it, I would suggest to work > directly on 15522. > > Le mar. 15 oct. 2019 à 15:01, Owen Leonard a écrit : > > > > Bug 15522, "New interface for revamped circulation rules" > > (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522) has > > been in limbo for a long time. It's a big change that relies on a > > patch that makes a big change: Bug 18936 - Convert issuingrules fields > > to circulation_rules > > (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18936). > > > > 18936 is particularly intimidating because of the extent of the > > changes. It's too much for one person to test thoroughly enough. > > > > If we agree that these bugs are worthy of moving forward, let's plan a > > coordinated effort to get them tested. I think it's probably too late > > for 11.19, but perhaps we could make a plan for the next release? A > > GBSD for just Bug 18936? > > > > Thanks, > > > > -- Owen > > > > -- > > Web Developer > > Athens County Public Libraries > > 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/ > _______________________________________________ > 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 kohanews at gmail.com Tue Oct 15 20:36:42 2019 From: kohanews at gmail.com (kohanews) Date: Tue, 15 Oct 2019 11:36:42 -0700 Subject: [Koha-devel] Call for News: October 2019 Newsletter Message-ID: <7055ff4d-58c0-1425-d212-f9eaf1a3ee80@gmail.com> I'm collecting news for the October 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 marka at pobox.com Thu Oct 24 15:24:54 2019 From: marka at pobox.com (Mark Alexander) Date: Thu, 24 Oct 2019 09:24:54 -0400 Subject: [Koha-devel] ISSUESLIP and old_checkouts in template code Message-ID: <1571923191-sup-507@x201s> I'm trying to access old_checkouts in an ISSUESLIP like this: [% FOREACH checkout IN old_checkouts %] This seems to return an empty list, which is not surprising given that the ISSUESLIP supposedly doesn't get passed the old_checkouts variable, according to the wiki: https://wiki.koha-community.org/wiki/Notices_with_Template_Toolkit I've been trying to figure out how to get old_checkouts passed to ISSUESLIP, but I'm not too familiar with the code. As best as I can tell, this needs to be done somewhere in C4/Members.pm, perhaps in the IssueSlip function, but it's not clear to me what I need to do. Any guidance would be appreciated. Thanks in advance! From jonathan.druart at bugs.koha-community.org Thu Oct 24 16:11:50 2019 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 24 Oct 2019 16:11:50 +0200 Subject: [Koha-devel] ISSUESLIP and old_checkouts in template code In-Reply-To: <1571923191-sup-507@x201s> References: <1571923191-sup-507@x201s> Message-ID: Hi Mark, Try this: @ Members.pm:596 @ sub IssueSlip { ); %loops = ( issues => [ map { $_->{issues}{itemnumber} } @checkouts ], + old_issues => [ $patron->old_checkouts->get_column('itemnumber') ], overdues => [ map { $_->{issues}{itemnumber} } @overdues ], opac_news => [ map { $_->{opac_news}{idnew} } @news ], ); Then, in the template of the notice: [% FOR c IN old_checkouts %] [% c.item.barcode %]

[% END %] Cheers, Jonathan Le jeu. 24 oct. 2019 à 15:24, Mark Alexander a écrit : > > > I'm trying to access old_checkouts in an ISSUESLIP like this: > > [% FOREACH checkout IN old_checkouts %] > > This seems to return an empty list, which is not surprising given that > the ISSUESLIP supposedly doesn't get passed the old_checkouts > variable, according to the wiki: > > https://wiki.koha-community.org/wiki/Notices_with_Template_Toolkit > > I've been trying to figure out how to get old_checkouts passed to > ISSUESLIP, but I'm not too familiar with the code. As best as I can > tell, this needs to be done somewhere in C4/Members.pm, perhaps in the > IssueSlip function, but it's not clear to me what I need to do. > > Any guidance would be appreciated. Thanks in advance! > _______________________________________________ > 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 indradg at gmail.com Fri Oct 25 06:25:20 2019 From: indradg at gmail.com (Indranil Das Gupta) Date: Fri, 25 Oct 2019 09:55:20 +0530 Subject: [Koha-devel] [Koha] Deny staff patrons permission to check in items issued to them. In-Reply-To: <5m74ngvdxxf29bbwdrtybpjh.1571977070951@email.android.com> References: <5m74ngvdxxf29bbwdrtybpjh.1571977070951@email.android.com> Message-ID: Hi James Circulation in koha (more specifically checkout aka issue) is controlled via a combination of 3 parameters: the branch, the borrower category and the itemtype. Library staff level operational granularity is not a function of Koha at the moment. Hope this helps Indranil Das Gupta L2C2 Technologies On Fri 25 Oct, 2019, 9:48 AM muirunyeri, wrote: > > Hello team, > Our library staff are allowed to borrow upto 5 items. Either junior books > or adult books. > We are looking for setting in koha that only allows the chief librarian > ability to checkin or checkout items to the staff patrons and deny any > other staff from doing it. We also want to ensure that staff donot checkin > items issued to them. > We also are in the process of introducing a new item type- Laptops and > tablets and would like them issued by a particular staff e.g. I.T. clerk. > How can we set this in koha?. > We are using koha version 17.05 > Someone please help. > Warm regards. > James > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at pobox.com Sat Oct 26 12:28:41 2019 From: marka at pobox.com (Mark Alexander) Date: Sat, 26 Oct 2019 06:28:41 -0400 Subject: [Koha-devel] ISSUESLIP and old_checkouts in template code In-Reply-To: References: <1571923191-sup-507@x201s> Message-ID: <1572085525-sup-3730@x201s> Excerpts from Jonathan Druart's message of 2019-10-24 16:11:50 +0200: > @ Members.pm:596 @ sub IssueSlip { > ); > %loops = ( > issues => [ map { $_->{issues}{itemnumber} } @checkouts ], > + old_issues => [ $patron->old_checkouts->get_column('itemnumber') ], > overdues => [ map { $_->{issues}{itemnumber} } @overdues ], > opac_news => [ map { $_->{opac_news}{idnew} } @news ], > ); This didn't quite work as expected; see the SQL error below. But it does get me on the right track, so thank you for that! I'll continue playing with this, perhaps by trying to get old_issues to look exactly like issues in the way it's constructed. Thanks again! SQL error follows: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' , , , , , , , , , , , , , , , , , , , , 3950, 26730, 26730, 28220, 26730, 28220' at line 1 [for Statement "SELECT `me`.`issue_id`, `me`.`borrowernumber`, `me`.`itemnumber`, `me`.`date_due`, `me`.`branchcode`, `me`.`returndate`, `me`.`lastreneweddate`, `me`.`renewals`, `me`.`auto_renew`, `me`.`auto_renew_error`, `me`.`timestamp`, `me`.`issuedate`, `me`.`onsite_checkout`, `me`.`note`, `me`.`notedate`, `me`.`noteseen` FROM `old_issues` `me` WHERE ( ( `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` = ? OR `itemnumber` IS NULL OR `itemnumber` IS NULL OR `itemnumber` = ? ) ) ORDER BY field(itemnumber, , , , , , , , , , , , , , , , , , , , , , 3950, 26730, 26730, 28220, 26730, 28220, 26730, 22133, 25086, 28133, 27996, 24500, 28480, 18222, 28491, , , 28494)" with ParamValues: 0='3950', 1='26730', 2='26730', 3='28220', 4='26730', 5='28220', 6='26730', 7='22133', 8='25086', 9='28133', 10='27996', 11='24500', 12='28480', 13='18222', 14='28491', 15='28494'] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832. ERROR PROCESSING TEMPLATE: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' , , , , , , , , , , , , , , , , , , , , 3950, 26730, 26730, 28220, 26730, 28220' at line 1 at /usr/share/koha/lib/Koha/Objects.pm line 269 at /usr/share/koha/lib/C4/Members.pm line 602. From martin.renvoize at ptfs-europe.com Tue Oct 29 17:41:46 2019 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 29 Oct 2019 16:41:46 +0000 Subject: [Koha-devel] Let's talk about the future of Bug 15522 In-Reply-To: References: Message-ID: These two bugs are near the top of my list to target early next cycle... So long as they apply cleanly and have had a little testing I'm keen to get them pushed early and fix any fallout during the cycle. *Martin Renvoize* Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize at ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com On Tue, 15 Oct 2019 at 14:31, Tomas Cohen Arazi wrote: > Let's have a GBSD next friday! > > El mar., 15 oct. 2019 a las 10:09, Jonathan Druart (< > jonathan.druart at bugs.koha-community.org>) escribió: > >> If we have a GBSD and a group focussing on it, I would suggest to work >> directly on 15522. >> >> Le mar. 15 oct. 2019 à 15:01, Owen Leonard a écrit >> : >> > >> > Bug 15522, "New interface for revamped circulation rules" >> > (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522) has >> > been in limbo for a long time. It's a big change that relies on a >> > patch that makes a big change: Bug 18936 - Convert issuingrules fields >> > to circulation_rules >> > (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18936). >> > >> > 18936 is particularly intimidating because of the extent of the >> > changes. It's too much for one person to test thoroughly enough. >> > >> > If we agree that these bugs are worthy of moving forward, let's plan a >> > coordinated effort to get them tested. I think it's probably too late >> > for 11.19, but perhaps we could make a plan for the next release? A >> > GBSD for just Bug 18936? >> > >> > Thanks, >> > >> > -- Owen >> > >> > -- >> > Web Developer >> > Athens County Public Libraries >> > 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/ >> _______________________________________________ >> 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 martin.renvoize at ptfs-europe.com Tue Oct 29 19:35:26 2019 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 29 Oct 2019 18:35:26 +0000 Subject: [Koha-devel] update MARC::Transform in debian.koha-community.org In-Reply-To: References: Message-ID: Hmm, I don't see MARC::Transform listed in Koha's dependencies so I'm surprised it's available via debian.koha-community.org at all. Our packaging maintainers would be who to contract for advice though, Mirko or Mason. Hope that helps, *Martin Renvoize* Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize at ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com On Thu, 3 Oct 2019 at 11:23, Stéphane Delaune wrote: > Hello, > > I'm Stéphane Delaune (aka reiveune) from BibLibre > > I am the developer of the Perl module MARC::Transform ( > https://metacpan.org/pod/MARC::Transform ), this module is in version > 0.003008 since april but, in debian.koha-community.org, the version is > only 0.003006 that is 5 years old (2 versions late, including a bugfix) > > I would like to know if someone is able to update this package in > debian.koha-community.org (and in > https://packages.qa.debian.org/libm/libmarc-transform-perl.html on which > the version is 0.003007) > > thank you in advance > > Stéphane Delaune > _______________________________________________ > 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 stephane.delaune at biblibre.com Wed Oct 30 08:47:04 2019 From: stephane.delaune at biblibre.com (=?UTF-8?Q?St=c3=a9phane_Delaune?=) Date: Wed, 30 Oct 2019 08:47:04 +0100 Subject: [Koha-devel] update MARC::Transform in debian.koha-community.org In-Reply-To: References: Message-ID: <99d92df3-253b-0cec-2ebe-ce8becd72f58@biblibre.com> Thanks Martin, Mirko or Mason, can you help me to update MARC::Transform to 0.003008 in debian.koha-community.org and in https://packages.qa.debian.org/libm/libmarc-transform-perl.html ? thank you in advance Stéphane Delaune Le 29/10/2019 à 19:35, Renvoize, Martin a écrit : > Hmm, > > I don't see MARC::Transform listed in Koha's dependencies so I'm > surprised it's available via debian.koha-community.org > at all.  Our packaging maintainers > would be who to contract for advice though, Mirko or Mason. > > Hope that helps, > > > *Martin Renvoize* > > > > > > Development Team Manager > > *Phone:* +44 (0) 1483 378728 > > > > *Mobile:* +44 (0) 7725 985 636 > > *Email:* martin.renvoize at ptfs-europe.com > > > > > *Fax:* +44 (0) 800 756 6384 > > > > > www.ptfs-europe.com > > Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30 > > > The information contained in this email message may be privileged, > confidential and protected from disclosure. If you are not the > intended recipient, any dissemination, distribution or copying is > strictly prohibited. If you think that you have received this email > message in error, please email the sender at info at ptfs-europe.com > > > > > > On Thu, 3 Oct 2019 at 11:23, Stéphane Delaune > > > wrote: > > Hello, > > I'm Stéphane Delaune (aka reiveune) from BibLibre > > I am the developer of the Perl module MARC::Transform ( > https://metacpan.org/pod/MARC::Transform ), this module is in version > 0.003008 since april but, in debian.koha-community.org > , the version is > only 0.003006 that is 5 years old (2 versions late, including a > bugfix) > > I would like to know if someone is able to update this package in > debian.koha-community.org (and in > https://packages.qa.debian.org/libm/libmarc-transform-perl.html on > which > the version is 0.003007) > > thank you in advance > > Stéphane Delaune > _______________________________________________ > 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 fridolin.somers at biblibre.com Wed Oct 30 23:58:47 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Wed, 30 Oct 2019 23:58:47 +0100 Subject: [Koha-devel] Koha 31/10 Message-ID: Feeling depressed ? Oppressed by light ? Enjoy our "dark" theme : https://demo.biblibre.com/ https://intranet-demo.biblibre.com/ Best regards, -- Fridolin SOMERS BibLibre, France - software and system maintainer From hagud at orex.es Thu Oct 31 11:22:49 2019 From: hagud at orex.es (Hugo Agud) Date: Thu, 31 Oct 2019 11:22:49 +0100 Subject: [Koha-devel] ElasticSearch Testing Message-ID: Good morning I am testing koha performance under different configuration and now I am testing koha zebra vs ElasticSearch 5.5 ,5.6 and 6.3 and I am facing an issue thant I can't solve, now I am going to install kohadev with ES to check if it works. The issue is that biblio search with more than one results gets an internal server error Can't locate object method "index_name" via package "Catmandu::Store::ElasticSearch" at /usr/share/koha/lib/Koha/SearchEngine/Elasticsearch/Search.pm line 407. I have manually forced the index_name, but same behaviour, on the other hand there is no problem of searching authorities... somebody has faced a similar problem? kindest regards Hugo -- *Hugo Agud - Orex Digital * *www.orex.es * [image: www.orex.es/koha] [image: www.orex.es/vufind] Director Passeig Comte Vilardaga, 118 3-3 08980 -Sant Feliu de Llobregat - Tel: 933 856 138 hagud at orex.es · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje contiene información que puede ser CONFIDENCIAL y/o de USO RESTRINGIDO. Si usted no es el receptor deseado del mensaje (ni está autorizado a recibirlo por el remitente), no está autorizado a copiar, reenviar o divulgar el mensaje o su contenido. Si ha recibido este mensaje por error, por favor, notifíquenoslo inmediatamente y bórrelo de su sistema. -------------- next part -------------- An HTML attachment was scrubbed... URL: