From kohanews at gmail.com  Fri Jul  1 02:37:00 2016
From: kohanews at gmail.com (kohanews)
Date: Thu, 30 Jun 2016 17:37:00 -0700
Subject: [Koha-devel] Koha Community Newsletter: June 2016
Message-ID: <5775BB2C.7030700@gmail.com>

Fellow Koha users:

The Koha Community Newsletter for June 2016 is here:
https://koha-community.org/koha-community-newsletter-june-2016/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

Thanks!

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160630/b76ec8ed/attachment.html>

From payal.mangyani3 at gmail.com  Fri Jul  1 09:43:52 2016
From: payal.mangyani3 at gmail.com (Payal Mangyani)
Date: Fri, 1 Jul 2016 13:13:52 +0530
Subject: [Koha-devel] regarding authentication
Message-ID: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>

Hello,
I am new to perl as well as to koha and I want to modify Koha's code for
authentication such that if a user with user name let say admin is logged
in and meanwhile someone else wants to login with the same user name that
is admin but with different ip address then the koha should restrict this
activity.
If user logged in has the following details -
username-admin
ip-192.168.1.129
and if another user try to login with the following -
username-admin
ip-192.168.1.130
Then that user should not be able to logged in.

I have been reading the Auth.pm file, it has code regarding authentication
and I am unable to find that where the user is allowed to login after
successful authentication as I want to put my code at that place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160701/b4545fd2/attachment.html>

From arthur.suzuki at univ-lyon3.fr  Fri Jul  1 17:01:49 2016
From: arthur.suzuki at univ-lyon3.fr (SUZUKI Arthur)
Date: Fri, 1 Jul 2016 17:01:49 +0200
Subject: [Koha-devel]  Read suggestions plugin
In-Reply-To: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>
References: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>
Message-ID: <577685DD.5050908@univ-lyon3.fr>

Hi Devs,
I've been implementing a first prototype of what may looks like "Amazon 
buy suggestions" like "other users who have bought this also bought...."
It provides a list of similar references based on what other borrowers 
has previously issued.

If anyone would like to test this it is available here : 
https://github.com/Liliputech/KohaReadSuggestion

Hope you'll like this work in progress.
Special thanks to Kile Hall whose previous and current work on Koha 
Plugin System has really helped me a lot while designing this.
More information on installing plugins here : 
http://bywatersolutions.com/2013/01/23/koha-plugin-system-coming-soon/

Thanks to the whole Koha community for the great software and clean code 
and to Kohala for the organization of the Koha Symposium in France, Lyon.
Best regards,

Arthur Suzuki
Librarians IT Team,
University Jean Moulin Lyon 3

From jonathan.druart at bugs.koha-community.org  Fri Jul  1 17:02:45 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 1 Jul 2016 16:02:45 +0100
Subject: [Koha-devel] Extending the action_logs table
In-Reply-To: <CABZfb=XBE1yHr6qJNA6FXCwDZjeCz3wnT4XHMRhkqk+D_XX+3w@mail.gmail.com>
References: <CABZfb=XBE1yHr6qJNA6FXCwDZjeCz3wnT4XHMRhkqk+D_XX+3w@mail.gmail.com>
Message-ID: <CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>

I don't have any suggestions. The new column sounds like a good and
easy way to do that.

2016-06-28 18:37 GMT+01:00 Tomas Cohen Arazi <tomascohen at gmail.com>:
> Hi everyone, I started to work on logging Holds actions (Bug 14642). One of
> the interesting things to log is the context in which those actions take
> place (OPAC, staff, CLI scripts).
>
> Do u have any opinion on the best way to do it besides just adding an
> 'interface' column or smth similar?
>
> Regards
> --
> Tom?s Cohen Arazi
> Theke Solutions (https://theke.io)
> ? +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 bargioni at pusc.it  Fri Jul  1 17:02:44 2016
From: bargioni at pusc.it (Stefano Bargioni)
Date: Fri, 1 Jul 2016 17:02:44 +0200
Subject: [Koha-devel] libsearch-elasticsearch-perl and liblog-any-perl
In-Reply-To: <CAJzKNY7fPT6qEh9o2RDtoUzi_=uMSh7foFyXEM66+MfV_UHRNA@mail.gmail.com>
References: <F2C09583-167A-4BD3-9401-7DE4518E8694@pusc.it>
	<BY2PR0401MB1752C636E5029C54A42FC31FC62D0@BY2PR0401MB1752.namprd04.prod.outlook.com>
	<4C5BCD9D-5035-40BE-9A32-5AC60C2BAACE@pusc.it>
	<CA+95qVRqvf3=MQj0o+0YYaqRznLoG5WCRm-16q=uLXXmLiNQeA@mail.gmail.com>
	<B1324BD9-7FF0-4789-BDBA-6DB03AF0DC14@pusc.it>
	<CAJzKNY5fQd+Nw4LGE3_v2=+xnYrHPRBFMMJQjChHDR6KvN3=tw@mail.gmail.com>
	<1BD8DDFA-F818-47CF-889C-988B304417CA@pusc.it>
	<CAJzKNY5eDCOsTtTgtD-d+2wLQc=PdEL9qs9rR_gj7zh==9U-nw@mail.gmail.com>
	<886E737F-8946-4A42-B85F-3036CC5F23FF@pusc.it>
	<CAJzKNY7fPT6qEh9o2RDtoUzi_=uMSh7foFyXEM66+MfV_UHRNA@mail.gmail.com>
Message-ID: <E4B39D77-C842-4177-888C-B6D9C2A6AC8C@pusc.it>

Hi, Jonathan:
first of all, I started a fresh Koha 16.05 installation, on Debian 8.5.
This means that tables for Elasticsearch are not populated by the installer.

I populated them using the attached script, quite completely copied from the 3.23.00.050 entry of updatedatabase.pl, as you suggested.
Then I rebuilt the Elasticsearch indices, and tested some queries.
Here are some results:

- query "a" returns 362 bibs using ES, and 1949 (all bib records) using Zebra
- sn:N returns 0 records with ES; you have to use sn,wrdl:N
- a query on auth record fails using ES, tracing the error in opac-error.log
- in queries with ES you have to use the exact accented word (universit?, ?tudes, ...)

Zeno Tajoli suggested me to ask you and Fr?d?ric Demians to backport on 16.05 the progress on Elasticsearch you'll add to the master. Thanks for your opinion.
Unfortunately, as a deputy director of a library, I can't help you much more than this, especially with new bug reports. Sorry.
Cheers. Stefano


> On 27 giu 2016, at 14:09, Jonathan Druart <jonathan.druart at bugs.koha-community.org> wrote:
> 
> No, I have much more mappings defined: http://pastebin.com/YJFNa79Q
> 
> You should try to repopulate the tables used by elastic search (see
> entry 3.23.00.050 of updatedatabase.pl) and then do a full reindex.
> 
> 2016-06-27 10:37 GMT+01:00 Stefano Bargioni <bargioni at pusc.it>:
>> Hi, Jonathan,
>> sorry: I typed "..." to cut off the MARC record. Bibs are in the source field and look good.
>> 
>> About mapping:
>> 
>> # curl 'http://localhost:9200/_all/_mapping'
>> {"koha_robin_biblios":{"mappings":{"data":{"properties":{"_all.phrase":{"type":"string","analyzer":"analyser_phrase"},"record":{"type":"string","store":true,"include_in_all":false}}}}}}
>> 
>> Is it correct?
>> Thx. Stefano
>> 
>>> On 24 giu 2016, at 18:33, Jonathan Druart <jonathan.druart at bugs.koha-community.org> wrote:
>>> 
>>> "_source":{"record":...,"_id":"1"}
>>> Is it the entire data? :)
>>> If yes, your first record is ":...;" and nothing else.
>>> It should be something like
>>> "_source":{"title":[["M?ga
>>> casse-t?te"]],"homebranch":[["MAURES"]],"publisher__facet":[["Nathan"]],
>>> [....]}
>>> 
>>> Check at the field/mapping tables: search_field, search_marc_map,
>>> search_marc_to_field. They should be fully populated.
>>> Then rebuild the biblio index using -d (for delete!)
>>> 
>>> 2016-06-24 17:21 GMT+01:00 Stefano Bargioni <bargioni at pusc.it>:
>>>> koha-conf.xml seems correct:
>>>> 
>>>> <elasticsearch>
>>>>    <server>localhost:9200</server>      <!-- may be repeated to include all servers on your cluster -->
>>>>    <index_name>koha_robin</index_name>  <!-- should be unique amongst all the indices on your cluster. _biblios and _authorities will be appended. -->
>>>> </elasticsearch>
>>>> 
>>>> sb
>>>> 
>>>>> On 24 giu 2016, at 18:09, Jonathan Druart <jonathan.druart at bugs.koha-community.org> wrote:
>>>>> 
>>>>> Hi Stephano,
>>>>> 
>>>>> Are you sure "koha_robin" is the index_name defined in your koha-conf.xml file?
>>>>> Search for the "elasticsearch" tag in this file.
>>>>> 
>>>>> Cheers,
>>>>> Jonathan
>>>>> 
>>>>> 2016-06-24 16:51 GMT+01:00  <bargioni at pusc.it>:
>>>>>> Nope, MARC21.
>>>>>> I verified that Elasticsearch contains my records:
>>>>>> 
>>>>>> $ curl 'http://localhost:9200/koha_robin_biblios/data/1?pretty'
>>>>>> {
>>>>>> "_index" : "koha_robin_biblios",
>>>>>> "_type" : "data",
>>>>>> "_id" : "1",
>>>>>> "_version" : 1,
>>>>>> "found" : true,
>>>>>> "_source":{"record":...,"_id":"1"}
>>>>>> }
>>>>>> 
>>>>>> Trying to debugging a search with "perl -d", it seems that the query is not correctly passed to Elasticsearch, because it always returns no results.
>>>>>> Some hints for a better debug?
>>>>>> Thx again. Stefano
>>>>>> 
>>>>>>> On 23 giu 2016, at 22:24, Chris Cormack <chris at bigballofwax.co.nz> wrote:
>>>>>>> 
>>>>>>> Hi Stefano
>>>>>>> 
>>>>>>> I wonder if this is a bug in the UNIMARC support, are you using UNIMARC?
>>>>>>> 
>>>>>>> Chris
>>>>>>> 
>>>>>>> On 24 June 2016 at 04:01,  <bargioni at pusc.it> wrote:
>>>>>>>> Thx, Mark, everything is fine, including the rebuild_elastic_search.pl.
>>>>>>>> Now Elasticsearch contains my ~1000 bib records.
>>>>>>>> But no results from searches in Koha, both opac and staff; and nothing in /var/log/koha, unfortunately.
>>>>>>>> Any idea?
>>>>>>>> Stefano
>>>>>>>> 
>>>>>>>>> On 23 giu 2016, at 13:08, Mark Tompsett <mtompset at hotmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Greetings,
>>>>>>>>> 
>>>>>>>>> While working on
>>>>>>>>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16618, I had
>>>>>>>>> issues installing underlying Elastic Search libraries too. This is how I
>>>>>>>>> solved them, though this may
>>>>>>>>> or may not be the best way.
>>>>>>>>> 
>>>>>>>>> --- BEGIN SNIPPET ---
>>>>>>>>> And in case you didn't have elastic search stuff installed:
>>>>>>>>> echo deb http://packages.elastic.co/elasticsearch/1.7/debian stable main |
>>>>>>>>> sudo tee /etc/apt/sources.list.d/elasticsearch.list
>>>>>>>>> wget -O- https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key
>>>>>>>>> add -
>>>>>>>>> sudo apt-get update
>>>>>>>>> 
>>>>>>>>> cd ~
>>>>>>>>> wget
>>>>>>>>> http://debian.koha-community.org/koha/otherthings/elasticsearch_deps.tar.gz
>>>>>>>>> tar xvf elasticsearch_deps.tar.gz
>>>>>>>>> cd es_deps
>>>>>>>>> sudo dpkg i lib*
>>>>>>>>> sudo apt-get install -f
>>>>>>>>> --- END SNIPPET ---
>>>>>>>>> 
>>>>>>>>> GPML,
>>>>>>>>> Mark Tompsett
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> I'd like to show Koha running with Elasticsearch at the incoming KohaLa's Symposium in Lyon.
>>>>>>>>>> I have a Debian 8.5 + Koha 16.05 virtual machine.
>>>>>>>>>> Following [1] and [2], I installed Elasticsearch.
>>>>>>>>>> However, installing related Perl modules, I get this error (translated from Italian):
>>>>>>>>>> 
>>>>>>>>>> libsearch-elasticsearch-perl depends on liblog-any-perl (>= 1.02); but:
>>>>>>>>>> installed version of liblog-any-perl is 0.15-1.
>>>>>>>>>> 
>>>>>>>>>> There is something about liblog-any-perl >0.15-1 in [3], but it seems not stable.
>>>>>>>>>> 
>>>>>>>>>> Any help?
>>>>>>>>>> Thx. Stefano
>>>>>>>>>> 
>>>>>>>>>> [1] https://wiki.koha-community.org/wiki/Elasticsearch
>>>>>>>>>> [2] http://debian.koha-community.org/koha/otherthings/
>>>>>>>>>> [3] https://packages.debian.org/search?keywords=liblog-any-perl
>>>>>>>> _______________________________________________
>>>>>>>> Koha-devel mailing list
>>>>>>>> Koha-devel at lists.koha-community.org
>>>>>>>> http://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
>>>>>> http://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
>>>>> http://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
>>>> http://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
>>> http://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
> http://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: populate_tables_elasticsearch.pl.zip
Type: application/zip
Size: 786 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160701/5b7ddeea/attachment.zip>

From tomascohen at gmail.com  Fri Jul  1 17:13:00 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 01 Jul 2016 15:13:00 +0000
Subject: [Koha-devel] Extending the action_logs table
In-Reply-To: <CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>
References: <CABZfb=XBE1yHr6qJNA6FXCwDZjeCz3wnT4XHMRhkqk+D_XX+3w@mail.gmail.com>
	<CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>
Message-ID: <CABZfb=Vpu9p3WR7h77Zajpa5Nf7k3owGGruD5+2cv=zronaYHw@mail.gmail.com>

Thanks for your answers.

El vie., 1 jul. 2016 a las 12:03, Jonathan Druart (<
jonathan.druart at bugs.koha-community.org>) escribi?:

> I don't have any suggestions. The new column sounds like a good and
> easy way to do that.
>
> 2016-06-28 18:37 GMT+01:00 Tomas Cohen Arazi <tomascohen at gmail.com>:
> > Hi everyone, I started to work on logging Holds actions (Bug 14642). One
> of
> > the interesting things to log is the context in which those actions take
> > place (OPAC, staff, CLI scripts).
> >
> > Do u have any opinion on the best way to do it besides just adding an
> > 'interface' column or smth similar?
> >
> > Regards
> > --
> > Tom?s Cohen Arazi
> > Theke Solutions (https://theke.io)
> > ? +54 9351 3513384
> > GPG: B2F3C15F
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://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
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160701/73e37d9d/attachment-0001.html>

From jonathan.druart at bugs.koha-community.org  Fri Jul  1 17:22:18 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 1 Jul 2016 16:22:18 +0100
Subject: [Koha-devel] libsearch-elasticsearch-perl and liblog-any-perl
In-Reply-To: <E4B39D77-C842-4177-888C-B6D9C2A6AC8C@pusc.it>
References: <F2C09583-167A-4BD3-9401-7DE4518E8694@pusc.it>
	<BY2PR0401MB1752C636E5029C54A42FC31FC62D0@BY2PR0401MB1752.namprd04.prod.outlook.com>
	<4C5BCD9D-5035-40BE-9A32-5AC60C2BAACE@pusc.it>
	<CA+95qVRqvf3=MQj0o+0YYaqRznLoG5WCRm-16q=uLXXmLiNQeA@mail.gmail.com>
	<B1324BD9-7FF0-4789-BDBA-6DB03AF0DC14@pusc.it>
	<CAJzKNY5fQd+Nw4LGE3_v2=+xnYrHPRBFMMJQjChHDR6KvN3=tw@mail.gmail.com>
	<1BD8DDFA-F818-47CF-889C-988B304417CA@pusc.it>
	<CAJzKNY5eDCOsTtTgtD-d+2wLQc=PdEL9qs9rR_gj7zh==9U-nw@mail.gmail.com>
	<886E737F-8946-4A42-B85F-3036CC5F23FF@pusc.it>
	<CAJzKNY7fPT6qEh9o2RDtoUzi_=uMSh7foFyXEM66+MfV_UHRNA@mail.gmail.com>
	<E4B39D77-C842-4177-888C-B6D9C2A6AC8C@pusc.it>
Message-ID: <CAJzKNY4SEf+Qe-Vs5KocmJurmKD4Rjbnei=y9F05F84-qTTM5A@mail.gmail.com>

2016-07-01 16:02 GMT+01:00 Stefano Bargioni <bargioni at pusc.it>:
> Hi, Jonathan:
> first of all, I started a fresh Koha 16.05 installation, on Debian 8.5.
> This means that tables for Elasticsearch are not populated by the installer.

I have opened a new bug report:
Bug 16838 - Elasticsearch - mapping tables are not populated on new installs

> I populated them using the attached script, quite completely copied from the 3.23.00.050 entry of updatedatabase.pl, as you suggested.
> Then I rebuilt the Elasticsearch indices, and tested some queries.
> Here are some results:
>
> - query "a" returns 362 bibs using ES, and 1949 (all bib records) using Zebra
> - sn:N returns 0 records with ES; you have to use sn,wrdl:N
> - a query on auth record fails using ES, tracing the error in opac-error.log
> - in queries with ES you have to use the exact accented word (universit?, ?tudes, ...)
>
> Zeno Tajoli suggested me to ask you and Fr?d?ric Demians to backport on 16.05 the progress on Elasticsearch you'll add to the master. Thanks for your opinion.
> Unfortunately, as a deputy director of a library, I can't help you much more than this, especially with new bug reports. Sorry.
> Cheers. Stefano
>
>
>> On 27 giu 2016, at 14:09, Jonathan Druart <jonathan.druart at bugs.koha-community.org> wrote:
>>
>> No, I have much more mappings defined: http://pastebin.com/YJFNa79Q
>>
>> You should try to repopulate the tables used by elastic search (see
>> entry 3.23.00.050 of updatedatabase.pl) and then do a full reindex.
>>
>> 2016-06-27 10:37 GMT+01:00 Stefano Bargioni <bargioni at pusc.it>:
>>> Hi, Jonathan,
>>> sorry: I typed "..." to cut off the MARC record. Bibs are in the source field and look good.
>>>
>>> About mapping:
>>>
>>> # curl 'http://localhost:9200/_all/_mapping'
>>> {"koha_robin_biblios":{"mappings":{"data":{"properties":{"_all.phrase":{"type":"string","analyzer":"analyser_phrase"},"record":{"type":"string","store":true,"include_in_all":false}}}}}}
>>>
>>> Is it correct?
>>> Thx. Stefano
>>>
>>>> On 24 giu 2016, at 18:33, Jonathan Druart <jonathan.druart at bugs.koha-community.org> wrote:
>>>>
>>>> "_source":{"record":...,"_id":"1"}
>>>> Is it the entire data? :)
>>>> If yes, your first record is ":...;" and nothing else.
>>>> It should be something like
>>>> "_source":{"title":[["M?ga
>>>> casse-t?te"]],"homebranch":[["MAURES"]],"publisher__facet":[["Nathan"]],
>>>> [....]}
>>>>
>>>> Check at the field/mapping tables: search_field, search_marc_map,
>>>> search_marc_to_field. They should be fully populated.
>>>> Then rebuild the biblio index using -d (for delete!)
>>>>
>>>> 2016-06-24 17:21 GMT+01:00 Stefano Bargioni <bargioni at pusc.it>:
>>>>> koha-conf.xml seems correct:
>>>>>
>>>>> <elasticsearch>
>>>>>    <server>localhost:9200</server>      <!-- may be repeated to include all servers on your cluster -->
>>>>>    <index_name>koha_robin</index_name>  <!-- should be unique amongst all the indices on your cluster. _biblios and _authorities will be appended. -->
>>>>> </elasticsearch>
>>>>>
>>>>> sb
>>>>>
>>>>>> On 24 giu 2016, at 18:09, Jonathan Druart <jonathan.druart at bugs.koha-community.org> wrote:
>>>>>>
>>>>>> Hi Stephano,
>>>>>>
>>>>>> Are you sure "koha_robin" is the index_name defined in your koha-conf.xml file?
>>>>>> Search for the "elasticsearch" tag in this file.
>>>>>>
>>>>>> Cheers,
>>>>>> Jonathan
>>>>>>
>>>>>> 2016-06-24 16:51 GMT+01:00  <bargioni at pusc.it>:
>>>>>>> Nope, MARC21.
>>>>>>> I verified that Elasticsearch contains my records:
>>>>>>>
>>>>>>> $ curl 'http://localhost:9200/koha_robin_biblios/data/1?pretty'
>>>>>>> {
>>>>>>> "_index" : "koha_robin_biblios",
>>>>>>> "_type" : "data",
>>>>>>> "_id" : "1",
>>>>>>> "_version" : 1,
>>>>>>> "found" : true,
>>>>>>> "_source":{"record":...,"_id":"1"}
>>>>>>> }
>>>>>>>
>>>>>>> Trying to debugging a search with "perl -d", it seems that the query is not correctly passed to Elasticsearch, because it always returns no results.
>>>>>>> Some hints for a better debug?
>>>>>>> Thx again. Stefano
>>>>>>>
>>>>>>>> On 23 giu 2016, at 22:24, Chris Cormack <chris at bigballofwax.co.nz> wrote:
>>>>>>>>
>>>>>>>> Hi Stefano
>>>>>>>>
>>>>>>>> I wonder if this is a bug in the UNIMARC support, are you using UNIMARC?
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>> On 24 June 2016 at 04:01,  <bargioni at pusc.it> wrote:
>>>>>>>>> Thx, Mark, everything is fine, including the rebuild_elastic_search.pl.
>>>>>>>>> Now Elasticsearch contains my ~1000 bib records.
>>>>>>>>> But no results from searches in Koha, both opac and staff; and nothing in /var/log/koha, unfortunately.
>>>>>>>>> Any idea?
>>>>>>>>> Stefano
>>>>>>>>>
>>>>>>>>>> On 23 giu 2016, at 13:08, Mark Tompsett <mtompset at hotmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> While working on
>>>>>>>>>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16618, I had
>>>>>>>>>> issues installing underlying Elastic Search libraries too. This is how I
>>>>>>>>>> solved them, though this may
>>>>>>>>>> or may not be the best way.
>>>>>>>>>>
>>>>>>>>>> --- BEGIN SNIPPET ---
>>>>>>>>>> And in case you didn't have elastic search stuff installed:
>>>>>>>>>> echo deb http://packages.elastic.co/elasticsearch/1.7/debian stable main |
>>>>>>>>>> sudo tee /etc/apt/sources.list.d/elasticsearch.list
>>>>>>>>>> wget -O- https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key
>>>>>>>>>> add -
>>>>>>>>>> sudo apt-get update
>>>>>>>>>>
>>>>>>>>>> cd ~
>>>>>>>>>> wget
>>>>>>>>>> http://debian.koha-community.org/koha/otherthings/elasticsearch_deps.tar.gz
>>>>>>>>>> tar xvf elasticsearch_deps.tar.gz
>>>>>>>>>> cd es_deps
>>>>>>>>>> sudo dpkg i lib*
>>>>>>>>>> sudo apt-get install -f
>>>>>>>>>> --- END SNIPPET ---
>>>>>>>>>>
>>>>>>>>>> GPML,
>>>>>>>>>> Mark Tompsett
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> I'd like to show Koha running with Elasticsearch at the incoming KohaLa's Symposium in Lyon.
>>>>>>>>>>> I have a Debian 8.5 + Koha 16.05 virtual machine.
>>>>>>>>>>> Following [1] and [2], I installed Elasticsearch.
>>>>>>>>>>> However, installing related Perl modules, I get this error (translated from Italian):
>>>>>>>>>>>
>>>>>>>>>>> libsearch-elasticsearch-perl depends on liblog-any-perl (>= 1.02); but:
>>>>>>>>>>> installed version of liblog-any-perl is 0.15-1.
>>>>>>>>>>>
>>>>>>>>>>> There is something about liblog-any-perl >0.15-1 in [3], but it seems not stable.
>>>>>>>>>>>
>>>>>>>>>>> Any help?
>>>>>>>>>>> Thx. Stefano
>>>>>>>>>>>
>>>>>>>>>>> [1] https://wiki.koha-community.org/wiki/Elasticsearch
>>>>>>>>>>> [2] http://debian.koha-community.org/koha/otherthings/
>>>>>>>>>>> [3] https://packages.debian.org/search?keywords=liblog-any-perl
>>>>>>>>> _______________________________________________
>>>>>>>>> Koha-devel mailing list
>>>>>>>>> Koha-devel at lists.koha-community.org
>>>>>>>>> http://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
>>>>>>> http://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
>>>>>> http://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
>>>>> http://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
>>>> http://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
>> http://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  Fri Jul  1 17:44:54 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 1 Jul 2016 16:44:54 +0100
Subject: [Koha-devel] Read suggestions plugin
In-Reply-To: <577685DD.5050908@univ-lyon3.fr>
References: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>
	<577685DD.5050908@univ-lyon3.fr>
Message-ID: <CAJzKNY7ygBixmwExtBZYsm76YX9KBKRjdtT3Jg4enb6dVPN52Q@mail.gmail.com>

Hi Arthur,

Reading the code it will only work for UNIMARC, you should mention it
in the README and tell people which changes are needed to make it work
for MARC21 (and add a couple of lines to explain what the plugin
does).

Did you test it on a real DB, with lot of entries in old_issues? It
might be quite slow.

Why did you choose to create a plugin instead of something integrated
to Koha (and submit the patch on bugzilla)?

Cheers,
Jonathan

2016-07-01 16:01 GMT+01:00 SUZUKI Arthur <arthur.suzuki at univ-lyon3.fr>:
> Hi Devs,
> I've been implementing a first prototype of what may looks like "Amazon buy
> suggestions" like "other users who have bought this also bought...."
> It provides a list of similar references based on what other borrowers has
> previously issued.
>
> If anyone would like to test this it is available here :
> https://github.com/Liliputech/KohaReadSuggestion
>
> Hope you'll like this work in progress.
> Special thanks to Kile Hall whose previous and current work on Koha Plugin
> System has really helped me a lot while designing this.
> More information on installing plugins here :
> http://bywatersolutions.com/2013/01/23/koha-plugin-system-coming-soon/
>
> Thanks to the whole Koha community for the great software and clean code and
> to Kohala for the organization of the Koha Symposium in France, Lyon.
> Best regards,
>
> Arthur Suzuki
> Librarians IT Team,
> University Jean Moulin Lyon 3
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 arthur.suzuki at univ-lyon3.fr  Fri Jul  1 19:47:01 2016
From: arthur.suzuki at univ-lyon3.fr (SUZUKI Arthur)
Date: Fri, 01 Jul 2016 19:47:01 +0200
Subject: [Koha-devel] Read suggestions plugin
In-Reply-To: <CAJzKNY7ygBixmwExtBZYsm76YX9KBKRjdtT3Jg4enb6dVPN52Q@mail.gmail.com>
References: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>
	<577685DD.5050908@univ-lyon3.fr>
	<CAJzKNY7ygBixmwExtBZYsm76YX9KBKRjdtT3Jg4enb6dVPN52Q@mail.gmail.com>
Message-ID: <1EDDCB6F-E9F6-4837-BEFB-9011CD98B44C@univ-lyon3.fr>

To all your questions, yes sure!

About UNIMARC or MARC21, this is quite easy to implement, it just needs  some parameters to the report-step1 sub and template.

I tested it on our pre-production server, the query takes 1s at the maximum to scan the whole DB (i did only sub selects and inner join to get a reduced dataset).

"Release early, release often", i thought it would be much easier to implement first in a plugin plus it is nice to use this new feature.
And really easy to install without messing with custom patches and git branches.

Many ways to optimize:
SQL:
-create a table to store those lists, like an index?
-filter or aggregate results on several fields (type of documents, subject, country, author, whatever)?

Template:
-How to integrate into OPAC?

Also every text is hardcoded for now, I don't know yet if translation is available through the plugin system, this is to be investigated.

Otherwise yes, could be merged to core code but I would need help on this because I don't know much about the core Koha architecture.

Have a nice weekend,
Cheers
Arthur

Le 1 juillet 2016 17:44:54 UTC+02:00, Jonathan Druart <jonathan.druart at bugs.koha-community.org> a ?crit :
>Hi Arthur,
>
>Reading the code it will only work for UNIMARC, you should mention it
>in the README and tell people which changes are needed to make it work
>for MARC21 (and add a couple of lines to explain what the plugin
>does).
>
>Did you test it on a real DB, with lot of entries in old_issues? It
>might be quite slow.
>
>Why did you choose to create a plugin instead of something integrated
>to Koha (and submit the patch on bugzilla)?
>
>Cheers,
>Jonathan
>
>2016-07-01 16:01 GMT+01:00 SUZUKI Arthur <arthur.suzuki at univ-lyon3.fr>:
>> Hi Devs,
>> I've been implementing a first prototype of what may looks like
>"Amazon buy
>> suggestions" like "other users who have bought this also bought...."
>> It provides a list of similar references based on what other
>borrowers has
>> previously issued.
>>
>> If anyone would like to test this it is available here :
>> https://github.com/Liliputech/KohaReadSuggestion
>>
>> Hope you'll like this work in progress.
>> Special thanks to Kile Hall whose previous and current work on Koha
>Plugin
>> System has really helped me a lot while designing this.
>> More information on installing plugins here :
>>
>http://bywatersolutions.com/2013/01/23/koha-plugin-system-coming-soon/
>>
>> Thanks to the whole Koha community for the great software and clean
>code and
>> to Kohala for the organization of the Koha Symposium in France, Lyon.
>> Best regards,
>>
>> Arthur Suzuki
>> Librarians IT Team,
>> University Jean Moulin Lyon 3
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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
>http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160701/d3ed0a04/attachment.html>

From jonathan.druart at bugs.koha-community.org  Mon Jul  4 10:53:16 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 4 Jul 2016 09:53:16 +0100
Subject: [Koha-devel] regarding authentication
In-Reply-To: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>
References: <CAL-XD0CGst_wW=+pP=5BTePXZU4yRV5yOGG4ZT_iWWpgmp6=iA@mail.gmail.com>
Message-ID: <CAJzKNY5PhK1nRUohMK3DS3cUq3fLN8YEZmX+VdHEUTvgxcXa6Q@mail.gmail.com>

Hi Payal,

You will have to write quite lot of code to achieve this goal.
Currently we do not have the "user A is currently logged in"
information. And actually I am not sure how you could know that if the
user does not click on "logout".
The authentication checks are done in C4::Auth::checkauth

Regards,
Jonathan

2016-07-01 8:43 GMT+01:00 Payal Mangyani <payal.mangyani3 at gmail.com>:
> Hello,
> I am new to perl as well as to koha and I want to modify Koha's code for
> authentication such that if a user with user name let say admin is logged in
> and meanwhile someone else wants to login with the same user name that is
> admin but with different ip address then the koha should restrict this
> activity.
> If user logged in has the following details -
> username-admin
> ip-192.168.1.129
> and if another user try to login with the following -
> username-admin
> ip-192.168.1.130
> Then that user should not be able to logged in.
>
> I have been reading the Auth.pm file, it has code regarding authentication
> and I am unable to find that where the user is allowed to login after
> successful authentication as I want to put my code at that place.
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 paul.poulain at biblibre.com  Wed Jul  6 12:12:35 2016
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 6 Jul 2016 12:12:35 +0200
Subject: [Koha-devel] Extending the action_logs table
In-Reply-To: <CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>
References: <CABZfb=XBE1yHr6qJNA6FXCwDZjeCz3wnT4XHMRhkqk+D_XX+3w@mail.gmail.com>
	<CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>
Message-ID: <577CD993.9080903@biblibre.com>

Le 01/07/2016 17:02, Jonathan Druart a ?crit :
> I don't have any suggestions. The new column sounds like a good and
> easy way to do that.
+1
and it could be useful in other areas. For example, cataloguing = we've 
some bots that create/update records, for example for the SUDOC. With 
such a column available, we could differentiate "human" cataloguing and 
"bot" cataloguing.
We could also use this in circulation (SIP2 checkout or self-checkout or 
staff-interface standard checkout)
>
> 2016-06-28 18:37 GMT+01:00 Tomas Cohen Arazi <tomascohen at gmail.com>:
>> Hi everyone, I started to work on logging Holds actions (Bug 14642). One of
>> the interesting things to log is the context in which those actions take
>> place (OPAC, staff, CLI scripts).
>>
>> Do u have any opinion on the best way to do it besides just adding an
>> 'interface' column or smth similar?
>>
>> Regards
>> --
>> Tom?s Cohen Arazi
>> Theke Solutions (https://theke.io)
>> ? +54 9351 3513384
>> GPG: B2F3C15F
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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
> http://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/


-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From tomascohen at gmail.com  Wed Jul  6 12:45:41 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Wed, 06 Jul 2016 10:45:41 +0000
Subject: [Koha-devel] Extending the action_logs table
In-Reply-To: <577CD993.9080903@biblibre.com>
References: <CABZfb=XBE1yHr6qJNA6FXCwDZjeCz3wnT4XHMRhkqk+D_XX+3w@mail.gmail.com>
	<CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>
	<577CD993.9080903@biblibre.com>
Message-ID: <CABZfb=WDsw-o_fDK5cH_H8bF38q_OePXtAey5C2SiAP_n2iczQ@mail.gmail.com>

El mi?., 6 jul. 2016 a las 7:12, Paul Poulain (<paul.poulain at biblibre.com>)
escribi?:

> Le 01/07/2016 17:02, Jonathan Druart a ?crit :
> > I don't have any suggestions. The new column sounds like a good and
> > easy way to do that.
> +1
> and it could be useful in other areas. For example, cataloguing = we've
> some bots that create/update records, for example for the SUDOC. With
> such a column available, we could differentiate "human" cataloguing and
> "bot" cataloguing.
> We could also use this in circulation (SIP2 checkout or self-checkout or
> staff-interface standard checkout)
>

I did it relying on C4::Context->interface so it is just a matter of making
it handle more 'interfaces' and the relevant scripts set it correctly for
logactions to pick it. Or just pass it as a parameter to logactions :-D

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16829

Please test so we push it ASAP!

Regards
-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160706/ee6b2317/attachment.html>

From dearden at sarsf.org  Wed Jul  6 17:40:08 2016
From: dearden at sarsf.org (Doug Dearden)
Date: Wed, 6 Jul 2016 15:40:08 +0000
Subject: [Koha-devel] [Koha] New Kohaer question
In-Reply-To: <CAHVUE-t_TCot6FO23D4CfjvGJx7MkVbBDN_bfdJcgs-UMTPGyw@mail.gmail.com>
References: <CAHVUE-t_TCot6FO23D4CfjvGJx7MkVbBDN_bfdJcgs-UMTPGyw@mail.gmail.com>
Message-ID: <483582c6e51e411b84acdae489626b20@SAR-Mail-02.campus.sarsf.org>

Hi Jimmy,

I have installed Debian on a Mac, but not for use with Koha.  This is just a matter of matching the version of Debian you are installing with the processor that is in the Mac.  In my case it was an older Mac with the Motorola processor.  If you have newer hardware it probably has the intel processors.  If you still have OS X installed you can get all the hardware info by clicking on the apple icon and choosing "About this Mac".  You may need to look at the advanced info to see everything.  When you have that info you can download the correct Debian install and follow the installation instructions on the Debian website.  

Best,

Doug

-----Original Message-----
From: Koha [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Zhimin Chen
Sent: Friday, July 1, 2016 11:44 AM
To: koha-devel at lists.koha-community.org; koha at lists.katipo.co.nz
Subject: [Koha] New Kohaer question

Dear Kohaers,

Do you have any experience to install Koha in Mac os x? no Debian no VM.

If no, How do I install Debian in Mac machine? I would like re-image mac os
x with Debian.

Thanks,

Jimmy
_______________________________________________
Koha mailing list  http://koha-community.org
Koha at lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

From mirko at abunchofthings.net  Wed Jul  6 22:22:17 2016
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Wed, 6 Jul 2016 22:22:17 +0200
Subject: [Koha-devel] Next general IRC meeting: 3 August 2016
Message-ID: <c4c180c4-0cb0-ac1b-3ac1-7f629380f7f2@abunchofthings.net>

Hello everyone,

today's general IRC meeting was postponed due to lack of attendence
and urgent agenda items.

The next general Koha IRC meeting will be held on 3 August 2016, 10
UTC. Please add important items to the agenda in the wiki.[1]

Cheers,

Mirko


[1]
https://wiki.koha-community.org/wiki/General_IRC_meeting_3_August_2016


--

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net
http://meinkoha.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160706/927ca08c/attachment.pgp>

From mirko at abunchofthings.net  Wed Jul  6 22:29:17 2016
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Wed, 6 Jul 2016 22:29:17 +0200
Subject: [Koha-devel] Kohacon 2017 proposals: deadline 10 August 2016, 10 UTC
Message-ID: <14311a76-5f3f-57db-f5bf-b56f78f03715@abunchofthings.net>

Hello everyone (again),

the deadline to submit your proposals to host Kohacon 2017 is
10 August 2016, 10 UTC.

Please add your proposals to the wiki[1] and feel free to make an
announcement to the main Koha mailing list.

Cheers,

Mirko


[1] https://wiki.koha-community.org/wiki/KohaCon17_Proposals


--

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net
http://meinkoha.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160706/ab1976bd/attachment.pgp>

From M.de.Rooy at rijksmuseum.nl  Thu Jul  7 12:08:37 2016
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 7 Jul 2016 10:08:37 +0000
Subject: [Koha-devel] Koha::Object[s] improvements - call for discussions
In-Reply-To: <CACpVHfxYCTA_wHgG6Q+ZtwKr9wShckV_oj1twXUpbLGEX40A6Q@mail.gmail.com>
References: <CAJzKNY5gmYhFHK+rN1ZhX7ccmpBSOTEPP7MJ926YbBQxcL5uag@mail.gmail.com>
	<CACpVHfxYCTA_wHgG6Q+ZtwKr9wShckV_oj1twXUpbLGEX40A6Q@mail.gmail.com>
Message-ID: <VI1PR0501MB25916DDF097D60B3BE6A2CD5CE3B0@VI1PR0501MB2591.eurprd05.prod.outlook.com>

Not sure if we want $patron->{surname} = $surname;
If it goes via the Koha::Object, you have control. If you allow mangling the hash outside your object code, what could happen?


Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Kyle Hall
Verzonden: zondag 26 juni 2016 13:06
Aan: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
CC: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Koha::Object[s] improvements - call for discussions

Jonthan, I love these ideas and definitely think they would be major improvements to Koha::Object(s).

I would like to toss something else in as well. A while back I submitted bug 15759 as a concept: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15759

This bug does some pretty awesome things imo:

1) it let's us use a Koha::Object as if it is a hashref!

So, if we have the following:

my $patron = Koha::Patrons->find( $borrowernumber );

the following are functionally equivilent:

my $surname = $patron->surname();
my $surname = $patron->{surname};

So are these:

$patron->surname( $surname );
$paron->{surname} = $surname;

2) It prevents bugs

One problem right now is you may accidentally use $patron->{surname} when you should have used $patron->surname().
Perl does not report any errors if you do this so the bug can be hard to track down. Because of the above this is no longer an issue!

3) Most importantly, this let's us drop a Koha::Object into a script where we are already using a hashref with no further changes!

Any scripts that already use hashrefs will now be able to use Koha::Objects instead!

There is a downside, we need to go through the existing Koha::Object(s) classes and change any references to $self where it is treated as a hashref and update them. So a line like this:
$self->{_result} = ....
to this
$$self->{_result} = ....

It is a trivial change though that could easily be done by a script at the time the bug would be pushed to master.

What does everyone think? Would this be a worthwhile improvement?

Kyle



[http://widgets.ch-or.us/badge/convio/cff/4715/2706639]<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>

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 Sun, Jun 26, 2016 at 6:04 AM, Jonathan Druart <jonathan.druart at bugs.koha-community.org<mailto:jonathan.druart at bugs.koha-community.org>> wrote:
Hi devs,

At the KohaCon16 some of us have briefly talked about the limitations
of Koha::Object[s] we encounter when implementing new modules.
Koha::Object[s] has been pushed to master less than 18 months ago and
we already have more than 30 classes using it.
It permits to uniformise our way to code, use powerful objects and is
very easy for refactoring. I have been moving code from C4 to the Koha
namespace and it's very handy to just have to write a concise module
and automatically have the basic methods (CRUD and more).

However it seems that we need to clearly define what we need in a near
future and adapt it quickly if it's needed.

= Rooms for Improvement =
There are 3 main rooms for improvement:
 - DBIx::Class basic methods
 - DBIx::Class relationship accesses
 - Koha::Objects vs DBIx::Class objects

== DBIx::Class basic methods ==
If you want to access a method provided by DBIx::Class, like ->store,
->delete, ->is_changed, we need to create a silly method which just
calls the same method on the DBIx::Class object.
For instance, let's take Koha::Objects->is_changed
    sub is_changed {
        my ( $self, @columns ) = @_;
        return $self->_result()->is_changed(@columns);
    }

Possible solution:
It would be possible to modify our AUTOLOAD method and check if it's a
DBIX::Class method.
If it is a valid one, let's call it, otherwise carp something.

== DBIx::Class relationships ==
From a Koha::Objects,  the relationships provided by DBIx::Class will
not be automatically generated.
For instance, from a virtual shelf, you will not have access to the
items on the shelf.

You will have to create a method which will call the DBIx::Class
relevant relationship.
    sub get_contents {
        my ( $self ) = @_;
        my $contents = $self->{_result}->virtualshelfcontents;
        return $contents;
    }
This piece of code adds a get_contents method to Koha::Virtualshelf
and call the virtualshelfcontents relationship created by DBIx::Class.
Note that this is finally good here, it is better to call have a
get_contents method than virtualshelfcontents.
But we may prefer to redefine it in the schema file
(Koha::Schema::Result::Virtualshelve).

Possible solution:
Same as previously, it would be possible to modify our AUTOLOAD method
and check if it's a valid relationship.

== Koha::Objects vs DBIX::Class objects ==
We'd like to always manipulate the same kind of objects, to avoid
confusion when reading the code.
At the moment we already manipulate 2 different entities: hashref from
C4 and objects from Koha::Object. It's confusing and not so easy to
manage in the code. To add flexibility we have added a
Koha::Object->unblessed method to transform the object to an hashref,
it's not ideal but it ease the transition.
Anyway, from a Koha::Object if you want to retrieve data linked to
this object, you would like to get a Koha::Object object base, not a
DBIx::Class object base.
If we continue with the previous example, we will need to modify
get_contents like this:
    sub get_contents {
        my ( $self ) = @_;
        my $rs = $self->{_result}->virtualshelfcontents;
        my $contents = Koha::Virtualshelfcontents->_new_from_dbic( $rs );
        return $contents;
    }
Basically ->new_from_dbic will just create an empty
Koha::Virtualshelfcontents object and set the internal resultset. No
query or extra processing should be done here.

I do not know if the changes suggested (and already implemented in
some areas and patches in the queue) is consistent.
It's not very elegant to read, but it looks safe on the performance
side, despite the encapsulation problem we could see at first glance.

= Concerns =
== API ==
Some people raised concerns about the new API to lean.
But finally we stick on DBIx::Class method names, so it should not be
to hard to learn for new devs.
And... the modules in the Koha namespace are much more easier to
read/understand than the legacy code in C4.

== ResultSet ==
It seems that writing the following is not obvious for everybody:
# Create and store
my $biblio = Koha::Biblio->new( { title => "a title", [other => $data] } );
$biblio->store;

# Retrieve data
my $biblio = Koha::Biblios->find( $biblionumber );
my $biblio = Koha::Biblios->search( { title => "a title" });

# Access relationship
my $items = $biblio->items;
warn ref( $items ); # Koha::Items
warn ref( $items->first ); # Koha::Item

This looks very easy to read for me, feel free to suggest something else.

= A complete example =

At the moment, the more complete example in master (and 16.05) is the
Koha::Virtualshelf and Koha::Virtualshelves modules. It includes
several search methods, overwrite of the store method and some complex
methods as well as complete test coverage
(t/db_dependent/Virtualshelves.t)

= Alternatives =
If you think you can provide an alternative or an idea to
improve/replace our Koha::Object[s] implementation, do not hesitate, I
would be glad to review or even implement it!

If you want to discuss one of these point, add a new one, or have a
specific question, please answer this email.
We could talk about that during the next dev meeting as well.

Cheers,
Jonathan
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org<mailto:Koha-devel at lists.koha-community.org>
http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160707/099de4c9/attachment-0001.html>

From bargioni at pusc.it  Thu Jul  7 12:47:28 2016
From: bargioni at pusc.it (Stefano Bargioni)
Date: Thu, 7 Jul 2016 12:47:28 +0200
Subject: [Koha-devel] Extending the action_logs table
In-Reply-To: <577CD993.9080903@biblibre.com>
References: <CABZfb=XBE1yHr6qJNA6FXCwDZjeCz3wnT4XHMRhkqk+D_XX+3w@mail.gmail.com>
	<CAJzKNY7OGL-GEGANEx6Kq_RoSCJ8OCjqiMBs0ZsBhcsAthk0KQ@mail.gmail.com>
	<577CD993.9080903@biblibre.com>
Message-ID: <DB1DDA60-C21B-4813-AA90-90CBC2DA342B@pusc.it>

My +1, especially for scripts.
sb

> On 06 lug 2016, at 12:12, Paul Poulain <paul.poulain at biblibre.com> wrote:
> 
> Le 01/07/2016 17:02, Jonathan Druart a ?crit :
>> I don't have any suggestions. The new column sounds like a good and
>> easy way to do that.
> +1
> and it could be useful in other areas. For example, cataloguing = we've some bots that create/update records, for example for the SUDOC. With such a column available, we could differentiate "human" cataloguing and "bot" cataloguing.
> We could also use this in circulation (SIP2 checkout or self-checkout or staff-interface standard checkout)
>> 
>> 2016-06-28 18:37 GMT+01:00 Tomas Cohen Arazi <tomascohen at gmail.com>:
>>> Hi everyone, I started to work on logging Holds actions (Bug 14642). One of
>>> the interesting things to log is the context in which those actions take
>>> place (OPAC, staff, CLI scripts).
>>> 
>>> Do u have any opinion on the best way to do it besides just adding an
>>> 'interface' column or smth similar?
>>> 
>>> Regards
>>> --
>>> Tom?s Cohen Arazi
>>> Theke Solutions (https://theke.io)
>>> ? +54 9351 3513384
>>> GPG: B2F3C15F
>>> 
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> http://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
>> http://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/
> 
> 
> -- 
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 alex.sassmannshausen at gmail.com  Thu Jul  7 13:25:48 2016
From: alex.sassmannshausen at gmail.com (Alex Sassmannshausen)
Date: Thu, 07 Jul 2016 13:25:48 +0200
Subject: [Koha-devel] Koha::Object[s] improvements - call for discussions
In-Reply-To: <VI1PR0501MB25916DDF097D60B3BE6A2CD5CE3B0@VI1PR0501MB2591.eurprd05.prod.outlook.com>
References: <CAJzKNY5gmYhFHK+rN1ZhX7ccmpBSOTEPP7MJ926YbBQxcL5uag@mail.gmail.com>
	<CACpVHfxYCTA_wHgG6Q+ZtwKr9wShckV_oj1twXUpbLGEX40A6Q@mail.gmail.com>
	<VI1PR0501MB25916DDF097D60B3BE6A2CD5CE3B0@VI1PR0501MB2591.eurprd05.prod.outlook.com>
Message-ID: <874m814rlv.fsf@gmail.com>

Hello

Throwing in my 2? here too?

Kyle Hall writes:

> Jonthan, I love these ideas and definitely think they would be major
> improvements to Koha::Object(s).

Agreed.  My reservations I expressed at the hackfest were around us
losing the great documentation that is available with dbic by having
Koha::Objects wrappers around dbic.  However, with that caveat in mind,
I think your suggested improvements seem solid.  Especially as more dbic
documentation would become applicable through the transparent proxying
of dbic relationships and methods.

> I would like to toss something else in as well. A while back I
> submitted bug 15759 as a concept:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15759

I will comment this on the bug too, but, to make it part of this email
thread:

I have some reservations about this approach.

> 1) it let's us use a Koha::Object as if it is a hashref!
>
> So, if we have the following:
>
> my $patron = Koha::Patrons->find( $borrowernumber );
>
> the following are functionally equivilent:
>
> my $surname = $patron->surname();
>
> my $surname = $patron->{surname};
>
> So are these:
>
> $patron->surname( $surname );
>
> $paron->{surname} = $surname;

I fear this approach of intermingling hashrefs and objects will make
reading code harder, as it blurs boundaries between what should be
discrete entities: there is the object that represents a patron and then
there is a hashref that represents a patron.  Both are valid
representations, but they are different things.

To aid code legibility, it makes sense IMHO, to be clear about what we
are using.  The proposed change, while convenient, would obscure.

> 2) It prevents bugs
>
> One problem right now is you may accidentally use $patron->{surname}
> when you should have used $patron->surname().
>
> Perl does not report any errors if you do this so the bug can be hard
> to track down. Because of the above this is no longer an issue!

I agree that silently continuing with an undef value is problematic.  I
think if at all possible I would prefer to fix this problem though.

I think if a programmer mistakes an object for a hashref then that is an
mistake that the programmer needs to be aware of, rather than the
program silently correcting that mistake?

> 3) Most importantly, this let's us drop a Koha::Object into a script
> where we are already using a hashref with no further changes!
>
> Any scripts that already use hashrefs will now be able to use
> Koha::Objects instead!

I agree that it would help with the conversion to Koha::Objects, but I
think the cost would be to high: I think we'd end up making code that is
already tricky to understand even harder to understand, and would tempt
us to continue accumulating technical debt when we need to be reducing
that.

I appreciate all the work done by Jonathan (and others?) on C4
refactoring, in the process of shifting to Koha objects, and I think
that's the right way to continue.
Of course, I appreciate your work on proposing this change too ? it's
way easier to sit on the sidelines and critique, like I am doing here
;-)

> Kyle

Best wishes,

Alex

>
> * 
>
> 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 Sun, Jun 26, 2016 at 6:04 AM, Jonathan Druart
> <jonathan.druart at bugs.koha-community.org> wrote:
>
>     Hi devs,
>     
>     At the KohaCon16 some of us have briefly talked about the
>     limitations
>     of Koha::Object[s] we encounter when implementing new modules.
>     Koha::Object[s] has been pushed to master less than 18 months ago
>     and
>     we already have more than 30 classes using it.
>     It permits to uniformise our way to code, use powerful objects and
>     is
>     very easy for refactoring. I have been moving code from C4 to the
>     Koha
>     namespace and it's very handy to just have to write a concise
>     module
>     and automatically have the basic methods (CRUD and more).
>     
>     However it seems that we need to clearly define what we need in a
>     near
>     future and adapt it quickly if it's needed.
>     
>     = Rooms for Improvement =
>     There are 3 main rooms for improvement:
>     - DBIx::Class basic methods
>     - DBIx::Class relationship accesses
>     - Koha::Objects vs DBIx::Class objects
>     
>     == DBIx::Class basic methods ==
>     If you want to access a method provided by DBIx::Class, like -
>     >store,
>     ->delete, ->is_changed, we need to create a silly method which
>     just
>     calls the same method on the DBIx::Class object.
>     For instance, let's take Koha::Objects->is_changed
>     sub is_changed {
>     my ( $self, @columns ) = @_;
>     return $self->_result()->is_changed(@columns);
>     }
>     
>     Possible solution:
>     It would be possible to modify our AUTOLOAD method and check if
>     it's a
>     DBIX::Class method.
>     If it is a valid one, let's call it, otherwise carp something.
>     
>     == DBIx::Class relationships ==
>     From a Koha::Objects, the relationships provided by DBIx::Class
>     will
>     not be automatically generated.
>     For instance, from a virtual shelf, you will not have access to
>     the
>     items on the shelf.
>     
>     You will have to create a method which will call the DBIx::Class
>     relevant relationship.
>     sub get_contents {
>     my ( $self ) = @_;
>     my $contents = $self->{_result}->virtualshelfcontents;
>     return $contents;
>     }
>     This piece of code adds a get_contents method to
>     Koha::Virtualshelf
>     and call the virtualshelfcontents relationship created by
>     DBIx::Class.
>     Note that this is finally good here, it is better to call have a
>     get_contents method than virtualshelfcontents.
>     But we may prefer to redefine it in the schema file
>     (Koha::Schema::Result::Virtualshelve).
>     
>     Possible solution:
>     Same as previously, it would be possible to modify our AUTOLOAD
>     method
>     and check if it's a valid relationship.
>     
>     == Koha::Objects vs DBIX::Class objects ==
>     We'd like to always manipulate the same kind of objects, to avoid
>     confusion when reading the code.
>     At the moment we already manipulate 2 different entities: hashref
>     from
>     C4 and objects from Koha::Object. It's confusing and not so easy
>     to
>     manage in the code. To add flexibility we have added a
>     Koha::Object->unblessed method to transform the object to an
>     hashref,
>     it's not ideal but it ease the transition.
>     Anyway, from a Koha::Object if you want to retrieve data linked to
>     this object, you would like to get a Koha::Object object base, not
>     a
>     DBIx::Class object base.
>     If we continue with the previous example, we will need to modify
>     get_contents like this:
>     sub get_contents {
>     my ( $self ) = @_;
>     my $rs = $self->{_result}->virtualshelfcontents;
>     my $contents = Koha::Virtualshelfcontents->_new_from_dbic( $rs );
>     return $contents;
>     }
>     Basically ->new_from_dbic will just create an empty
>     Koha::Virtualshelfcontents object and set the internal resultset.
>     No
>     query or extra processing should be done here.
>     
>     I do not know if the changes suggested (and already implemented in
>     some areas and patches in the queue) is consistent.
>     It's not very elegant to read, but it looks safe on the
>     performance
>     side, despite the encapsulation problem we could see at first
>     glance.
>     
>     = Concerns =
>     == API ==
>     Some people raised concerns about the new API to lean.
>     But finally we stick on DBIx::Class method names, so it should not
>     be
>     to hard to learn for new devs.
>     And... the modules in the Koha namespace are much more easier to
>     read/understand than the legacy code in C4.
>     
>     == ResultSet ==
>     It seems that writing the following is not obvious for everybody:
>     # Create and store
>     my $biblio = Koha::Biblio->new( { title => "a title", [other =>
>     $data] } );
>     $biblio->store;
>     
>     # Retrieve data
>     my $biblio = Koha::Biblios->find( $biblionumber );
>     my $biblio = Koha::Biblios->search( { title => "a title" });
>     
>     # Access relationship
>     my $items = $biblio->items;
>     warn ref( $items ); # Koha::Items
>     warn ref( $items->first ); # Koha::Item
>     
>     This looks very easy to read for me, feel free to suggest
>     something else.
>     
>     = A complete example =
>     
>     At the moment, the more complete example in master (and 16.05) is
>     the
>     Koha::Virtualshelf and Koha::Virtualshelves modules. It includes
>     several search methods, overwrite of the store method and some
>     complex
>     methods as well as complete test coverage
>     (t/db_dependent/Virtualshelves.t)
>     
>     = Alternatives =
>     If you think you can provide an alternative or an idea to
>     improve/replace our Koha::Object[s] implementation, do not
>     hesitate, I
>     would be glad to review or even implement it!
>     
>     If you want to discuss one of these point, add a new one, or have
>     a
>     specific question, please answer this email.
>     We could talk about that during the next dev meeting as well.
>     
>     Cheers,
>     Jonathan
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     http://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 kyle.m.hall at gmail.com  Thu Jul  7 14:26:31 2016
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Thu, 7 Jul 2016 08:26:31 -0400
Subject: [Koha-devel] Koha::Object[s] improvements - call for discussions
In-Reply-To: <874m814rlv.fsf@gmail.com>
References: <CAJzKNY5gmYhFHK+rN1ZhX7ccmpBSOTEPP7MJ926YbBQxcL5uag@mail.gmail.com>
	<CACpVHfxYCTA_wHgG6Q+ZtwKr9wShckV_oj1twXUpbLGEX40A6Q@mail.gmail.com>
	<VI1PR0501MB25916DDF097D60B3BE6A2CD5CE3B0@VI1PR0501MB2591.eurprd05.prod.outlook.com>
	<874m814rlv.fsf@gmail.com>
Message-ID: <CACpVHfz6-Uz5VWk8Mr5yjJtzE+x+JmpW-oMPfST=J1T1Zj3iiw@mail.gmail.com>

Thanks for the input. The bug started out as just a way to make the
improper use of objects as hashrefs trigger an error, but evolved when I
thought of this possibility. We can still make that happen, it still
requires the blessed hashref to be converted to a blessed scalar ref and
the class files will need updated. If this is generally considered a good
idea, I can submit a patch.

Kyle

<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>

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 Thu, Jul 7, 2016 at 7:25 AM, Alex Sassmannshausen <
alex.sassmannshausen at gmail.com> wrote:

> Hello
>
> Throwing in my 2? here too?
>
> Kyle Hall writes:
>
> > Jonthan, I love these ideas and definitely think they would be major
> > improvements to Koha::Object(s).
>
> Agreed.  My reservations I expressed at the hackfest were around us
> losing the great documentation that is available with dbic by having
> Koha::Objects wrappers around dbic.  However, with that caveat in mind,
> I think your suggested improvements seem solid.  Especially as more dbic
> documentation would become applicable through the transparent proxying
> of dbic relationships and methods.
>
> > I would like to toss something else in as well. A while back I
> > submitted bug 15759 as a concept:
> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15759
>
> I will comment this on the bug too, but, to make it part of this email
> thread:
>
> I have some reservations about this approach.
>
> > 1) it let's us use a Koha::Object as if it is a hashref!
> >
> > So, if we have the following:
> >
> > my $patron = Koha::Patrons->find( $borrowernumber );
> >
> > the following are functionally equivilent:
> >
> > my $surname = $patron->surname();
> >
> > my $surname = $patron->{surname};
> >
> > So are these:
> >
> > $patron->surname( $surname );
> >
> > $paron->{surname} = $surname;
>
> I fear this approach of intermingling hashrefs and objects will make
> reading code harder, as it blurs boundaries between what should be
> discrete entities: there is the object that represents a patron and then
> there is a hashref that represents a patron.  Both are valid
> representations, but they are different things.
>
> To aid code legibility, it makes sense IMHO, to be clear about what we
> are using.  The proposed change, while convenient, would obscure.
>
> > 2) It prevents bugs
> >
> > One problem right now is you may accidentally use $patron->{surname}
> > when you should have used $patron->surname().
> >
> > Perl does not report any errors if you do this so the bug can be hard
> > to track down. Because of the above this is no longer an issue!
>
> I agree that silently continuing with an undef value is problematic.  I
> think if at all possible I would prefer to fix this problem though.
>
> I think if a programmer mistakes an object for a hashref then that is an
> mistake that the programmer needs to be aware of, rather than the
> program silently correcting that mistake?
>
> > 3) Most importantly, this let's us drop a Koha::Object into a script
> > where we are already using a hashref with no further changes!
> >
> > Any scripts that already use hashrefs will now be able to use
> > Koha::Objects instead!
>
> I agree that it would help with the conversion to Koha::Objects, but I
> think the cost would be to high: I think we'd end up making code that is
> already tricky to understand even harder to understand, and would tempt
> us to continue accumulating technical debt when we need to be reducing
> that.
>
> I appreciate all the work done by Jonathan (and others?) on C4
> refactoring, in the process of shifting to Koha objects, and I think
> that's the right way to continue.
> Of course, I appreciate your work on proposing this change too ? it's
> way easier to sit on the sidelines and critique, like I am doing here
> ;-)
>
> > Kyle
>
> Best wishes,
>
> Alex
>
> >
> > *
> >
> > 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 Sun, Jun 26, 2016 at 6:04 AM, Jonathan Druart
> > <jonathan.druart at bugs.koha-community.org> wrote:
> >
> >     Hi devs,
> >
> >     At the KohaCon16 some of us have briefly talked about the
> >     limitations
> >     of Koha::Object[s] we encounter when implementing new modules.
> >     Koha::Object[s] has been pushed to master less than 18 months ago
> >     and
> >     we already have more than 30 classes using it.
> >     It permits to uniformise our way to code, use powerful objects and
> >     is
> >     very easy for refactoring. I have been moving code from C4 to the
> >     Koha
> >     namespace and it's very handy to just have to write a concise
> >     module
> >     and automatically have the basic methods (CRUD and more).
> >
> >     However it seems that we need to clearly define what we need in a
> >     near
> >     future and adapt it quickly if it's needed.
> >
> >     = Rooms for Improvement =
> >     There are 3 main rooms for improvement:
> >     - DBIx::Class basic methods
> >     - DBIx::Class relationship accesses
> >     - Koha::Objects vs DBIx::Class objects
> >
> >     == DBIx::Class basic methods ==
> >     If you want to access a method provided by DBIx::Class, like -
> >     >store,
> >     ->delete, ->is_changed, we need to create a silly method which
> >     just
> >     calls the same method on the DBIx::Class object.
> >     For instance, let's take Koha::Objects->is_changed
> >     sub is_changed {
> >     my ( $self, @columns ) = @_;
> >     return $self->_result()->is_changed(@columns);
> >     }
> >
> >     Possible solution:
> >     It would be possible to modify our AUTOLOAD method and check if
> >     it's a
> >     DBIX::Class method.
> >     If it is a valid one, let's call it, otherwise carp something.
> >
> >     == DBIx::Class relationships ==
> >     From a Koha::Objects, the relationships provided by DBIx::Class
> >     will
> >     not be automatically generated.
> >     For instance, from a virtual shelf, you will not have access to
> >     the
> >     items on the shelf.
> >
> >     You will have to create a method which will call the DBIx::Class
> >     relevant relationship.
> >     sub get_contents {
> >     my ( $self ) = @_;
> >     my $contents = $self->{_result}->virtualshelfcontents;
> >     return $contents;
> >     }
> >     This piece of code adds a get_contents method to
> >     Koha::Virtualshelf
> >     and call the virtualshelfcontents relationship created by
> >     DBIx::Class.
> >     Note that this is finally good here, it is better to call have a
> >     get_contents method than virtualshelfcontents.
> >     But we may prefer to redefine it in the schema file
> >     (Koha::Schema::Result::Virtualshelve).
> >
> >     Possible solution:
> >     Same as previously, it would be possible to modify our AUTOLOAD
> >     method
> >     and check if it's a valid relationship.
> >
> >     == Koha::Objects vs DBIX::Class objects ==
> >     We'd like to always manipulate the same kind of objects, to avoid
> >     confusion when reading the code.
> >     At the moment we already manipulate 2 different entities: hashref
> >     from
> >     C4 and objects from Koha::Object. It's confusing and not so easy
> >     to
> >     manage in the code. To add flexibility we have added a
> >     Koha::Object->unblessed method to transform the object to an
> >     hashref,
> >     it's not ideal but it ease the transition.
> >     Anyway, from a Koha::Object if you want to retrieve data linked to
> >     this object, you would like to get a Koha::Object object base, not
> >     a
> >     DBIx::Class object base.
> >     If we continue with the previous example, we will need to modify
> >     get_contents like this:
> >     sub get_contents {
> >     my ( $self ) = @_;
> >     my $rs = $self->{_result}->virtualshelfcontents;
> >     my $contents = Koha::Virtualshelfcontents->_new_from_dbic( $rs );
> >     return $contents;
> >     }
> >     Basically ->new_from_dbic will just create an empty
> >     Koha::Virtualshelfcontents object and set the internal resultset.
> >     No
> >     query or extra processing should be done here.
> >
> >     I do not know if the changes suggested (and already implemented in
> >     some areas and patches in the queue) is consistent.
> >     It's not very elegant to read, but it looks safe on the
> >     performance
> >     side, despite the encapsulation problem we could see at first
> >     glance.
> >
> >     = Concerns =
> >     == API ==
> >     Some people raised concerns about the new API to lean.
> >     But finally we stick on DBIx::Class method names, so it should not
> >     be
> >     to hard to learn for new devs.
> >     And... the modules in the Koha namespace are much more easier to
> >     read/understand than the legacy code in C4.
> >
> >     == ResultSet ==
> >     It seems that writing the following is not obvious for everybody:
> >     # Create and store
> >     my $biblio = Koha::Biblio->new( { title => "a title", [other =>
> >     $data] } );
> >     $biblio->store;
> >
> >     # Retrieve data
> >     my $biblio = Koha::Biblios->find( $biblionumber );
> >     my $biblio = Koha::Biblios->search( { title => "a title" });
> >
> >     # Access relationship
> >     my $items = $biblio->items;
> >     warn ref( $items ); # Koha::Items
> >     warn ref( $items->first ); # Koha::Item
> >
> >     This looks very easy to read for me, feel free to suggest
> >     something else.
> >
> >     = A complete example =
> >
> >     At the moment, the more complete example in master (and 16.05) is
> >     the
> >     Koha::Virtualshelf and Koha::Virtualshelves modules. It includes
> >     several search methods, overwrite of the store method and some
> >     complex
> >     methods as well as complete test coverage
> >     (t/db_dependent/Virtualshelves.t)
> >
> >     = Alternatives =
> >     If you think you can provide an alternative or an idea to
> >     improve/replace our Koha::Object[s] implementation, do not
> >     hesitate, I
> >     would be glad to review or even implement it!
> >
> >     If you want to discuss one of these point, add a new one, or have
> >     a
> >     specific question, please answer this email.
> >     We could talk about that during the next dev meeting as well.
> >
> >     Cheers,
> >     Jonathan
> >     _______________________________________________
> >     Koha-devel mailing list
> >     Koha-devel at lists.koha-community.org
> >     http://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
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160707/bdc5b7c8/attachment-0001.html>

From skushner at mplmain.mtpl.org  Thu Jul  7 17:55:05 2016
From: skushner at mplmain.mtpl.org (Scott Kushner)
Date: Thu, 7 Jul 2016 15:55:05 +0000
Subject: [Koha-devel] Error on Koha Dev Git install
Message-ID: <DC5B519605FEB74CA1A9F548F8CAFBB305AD1F42@EXCH2010.mplmain.mtpl.org>

Anyone seen this before and have a solution?

It's some kind of Apache permissions issue, but I'm not sure where.

I gave the directory 755 and www-data permisions..

Forbidden
You don't have permission to access / on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
________________________________
Apache/2.4.10 (Debian) Server at xxx.xx.x.xxx Port 8080


I am following these installation instructions...

https://wiki.koha-community.org/wiki/Install_and_Setup_Koha_to_use_Git_on_a_Development_Server

thanks,

Sincerely,

Scott Kushner
Systems Librarian
Middletown Public Library
55 New Monmouth Rd
Middletown, NJ 07748

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160707/3ed2bf44/attachment.html>

From eric.begin at inlibro.com  Thu Jul  7 18:23:52 2016
From: eric.begin at inlibro.com (=?ISO-8859-1?Q?Eric_B=E9gin?=)
Date: Thu, 07 Jul 2016 12:23:52 -0400
Subject: [Koha-devel] RE :  Error on Koha Dev Git install
Message-ID: <hdppg6ekgh3hhqh0d78y91cc.1467908548749@email.android.com>


    
Scott,
There is a slight difference the way the permissions are given in Apache 2.4.
Take a look at this :
https://httpd.apache.org/docs/current/en/upgrading.html#run-time
Cheers,
Eric B?ginSolutions inLibro inc.

-------- Message d'origine --------
De : Scott Kushner <skushner at mplmain.mtpl.org> 
Date : 07/07/2016  11:55  (GMT-05:00) 
? : "Koha Devel (koha-devel at lists.koha-community.org)" <koha-devel at lists.koha-community.org>, koha at lists.katipo.co.nz 
Objet : [Koha-devel] Error on Koha Dev Git install 

Anyone seen this before and have a solution? ?It?s some kind of Apache permissions issue, but I?m not sure where.?I gave the directory 755 and www-data permisions..?ForbiddenYou don't have permission to access / on this server.Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.Apache/2.4.10 (Debian) Server at xxx.xx.x.xxx Port 8080??I am following these installation instructions??https://wiki.koha-community.org/wiki/Install_and_Setup_Koha_to_use_Git_on_a_Development_Server?thanks,?Sincerely, ?Scott KushnerSystems LibrarianMiddletown Public Library55 New Monmouth RdMiddletown, NJ 07748?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160707/ae80ff37/attachment.html>

From paul.a at navalmarinearchive.com  Thu Jul  7 18:41:54 2016
From: paul.a at navalmarinearchive.com (Paul A)
Date: Thu, 07 Jul 2016 12:41:54 -0400
Subject: [Koha-devel] Error on Koha Dev Git install
In-Reply-To: <DC5B519605FEB74CA1A9F548F8CAFBB305AD1F42@EXCH2010.mplmain.
	mtpl.org>
Message-ID: <5.2.1.1.2.20160707122948.11331b88@pop.navalmarinearchive.com>

At 03:55 PM 7/7/2016 +0000, Scott Kushner wrote:
>Anyone seen this before and have a solution?
>Its some kind of Apache permissions issue, but Im not sure where.
>I gave the directory 755 and www-data permisions..
>
>Forbidden
>You don't have permission to access / on this server.

Yup, Apache (out of the box, all versions that I can remember over the last 
two decades) denies access to root (" / ") -- anything else would be a huge 
security risk.

So you don't have an Apache problem. And FYI, (you don't say what 
"directory" you're referring to), *most* (certainly all static) webpages 
should be 644.

>Additionally, a 404 Not Found error was encountered while trying to use an 
>ErrorDocument to handle the request.

Normal: if you can't get the request|page, it's "404" -- what do your error 
logs say???

Best -- Paul 


From mtompset at hotmail.com  Thu Jul  7 19:28:51 2016
From: mtompset at hotmail.com (Mark Tompsett)
Date: Thu, 7 Jul 2016 17:28:51 +0000
Subject: [Koha-devel] Error on Koha Dev Git install
In-Reply-To: <DC5B519605FEB74CA1A9F548F8CAFBB305AD1F42@EXCH2010.mplmain.mtpl.org>
References: <DC5B519605FEB74CA1A9F548F8CAFBB305AD1F42@EXCH2010.mplmain.mtpl.org>
Message-ID: <BY2PR0401MB175298D9912B6AA87E29D8B8C63B0@BY2PR0401MB1752.namprd04.prod.outlook.com>

Greetings,

https://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#403_errors_for_Gitified_or_git_clone_installs

GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160707/c0c83f23/attachment-0001.html>

From tomascohen at gmail.com  Sat Jul  9 14:06:25 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Sat, 09 Jul 2016 12:06:25 +0000
Subject: [Koha-devel] [Koha] Introducing "Mana" (central DB project)
In-Reply-To: <577CD754.1090607@biblibre.com>
References: <577CD754.1090607@biblibre.com>
Message-ID: <CABZfb=V4Lv1eHdQ1=AFU5gVSBc4vM+EGfKKCn8_tQscZ3r_ToA@mail.gmail.com>

That's great, Paul. I hope it is online soon!

Congrats Morgane!

El jue., 7 jul. 2016 20:46, Paul Poulain <paul.poulain at biblibre.com>
escribi?:

> Some months ago I sent an email to koha-devel, to announce that BibLibre
> was planning to work on a new project, dedicated to sharing informations
> between Koha
> (https://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc).
>
> I'm proud an happy to give you feedback about this project: things are
> moving quickly & nicely.
>
>   * *Morgane*, our intern -alex_a being the tutor) is doing a great job
> (you can congratulate her on #koha ;-) )
>   * we've named this project "*Mana*". It's a Maori word (once again
> :D), easy to pronounce & write.
> http://maoridictionary.co.nz/search?&keywords=mana : "*(verb)* to be
> legal, effectual, binding, authoritative, valid." I'll ask for
> mana.koha-community.org DNS entry soon !
>   * as announced by Morgane, we're using the same framework as for HEA
> for the server side. The code is available on our git:
> http://git.biblibre.com/biblibre/koha-mana (will be pushed later on
> git.koha-community.org). The DB is here, some webservice are already
> here & working.
>   * The koha-side is being worked, below are some screen shots.
>   * we changed some things compared to my initial RFC. Everything is on
> trello, splitted into cards (https://trello.com/b/BslL6i9p/mana-biblibre
> trello not public, claire, the owner is not here today, we'll change the
> status in a day or 2.) Note that there can be some French on trello,
> even if Morgane avoid it.
> We plan to have MANA working at the end of august, at least for
> subscriptions (pattern & numbering) sharing. Maybe also for SQL reports
> & vendors.
>
> Some screen shots & features descriptions:
>
>   in subscription management, you can now *share* a subscription
> pattern, by sending it to Mana:
>
> When you click on "share", after validation, you get a *feedback*:
>
>
>
> Anyone can then retrieve the numbering pattern & frequency calculation
> when creating a subscription (work being done this week). After the 1st
> screen of subscription creation, Koha will automatically query mana and
> check if there is some data available:
>
>
> The librarian will then be able to see what is available and get it
> locally in one click.
> Every time a librarian "get it locally", a counter will be incremented
> on Mana. Thus, if more than 1 frequency/pattern is submitted for a given
> title, the librarians should be able to see which one is "preferred" by
> other librarians.
>
> Additional features:
>   * we will create a script that will help populate Mana from a CSV. We
> will probably issue a RFF ("Request For File" ;-) ) later. Our idea is
> that we want to launch Mana with many data already available.
>   * comment. Any librarian will be able to add a comment to a shared
> data, as well as marking it as "obsolete".
>   * a syspref will be added to deactivate Mana (will be ON by default)
>
> Feel free to ask for more informations, I would be happy to answer !
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160709/aa79f288/attachment.html>

From jonathan.druart at bugs.koha-community.org  Sat Jul  9 15:07:16 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Sat, 9 Jul 2016 14:07:16 +0100
Subject: [Koha-devel] What's on in Koha devel #2
Message-ID: <CAJzKNY46DYa705ZveZbixRMEJQC6MzXasHbjZ4uB5hZbN7KqPw@mail.gmail.com>

Hi devs,

As usual the month following the KohaCon is quite quiet. And
especially when people from half of the world are on holiday  :)
So not much was going on during the last month and the tendency will
certainly be the same the for next month.
If you are in holiday and you become bored, you can still tests some patches!

= Refactoring =
On the refactoring side, I have started to move the subroutine of
C4::Members to the Koha namespace, I will need help for testing and
QA, see bug 16846 (Move patron related code to Koha::Patron).

= Performances =
Some words about the performances area: bug 16166 (Improve L1 cache
performance and safety) has just been pushed and must continue to
improve our caching mechanism. Note that bug 16715 (Koha::Cache - Use
Sereal for serialization) is going to be pushed and that we are
currently evaluating a new way to set the memcached configuration to
make it easily accessible from command line scripts and cronjobs (see
bug 16579 - Use separate memcached namespace for caching
koha-conf.xml). I should also add that bug 16365 (Selectively
introduce GetMarcStructure() "unsafe" variant for better performance)
is waiting for testers.

= Elastic Search =
A bug has been found for new installations, the mapping tables are not
populated by the installer. There is no patch currently to fix it, but
a bug report has been opened (bug 16838 - Elasticsearch - mapping
tables are not populated on new installs)
If you are interested in testing a funny enhancement, you should take
a look at bug 14899 (Mapping configuration page for Elastic search).
It proposes a way to define mappings between the MARC fields and the
indexer fields.

= Mana =
Paul Poulain already announced some months ago that a new internship
at BibLibre, Morgan, will work on a way to share data
between Koha libraries around the world. It seems that the work is
going well! The code is shared and can be tested. See the announcement
on the mainling list
(https://lists.katipo.co.nz/pipermail/koha/2016-July/045739.html)

= Koha::Object[s] =
I have sent an email on koha-devel to discuss about our
Koha::Object[s] based class:
http://lists.koha-community.org/pipermail/koha-devel/2016-June/042782.html
It would be great to see more devs involved in this discussion!

= Bugs which need some love =
In the previous email I told you that 2 critical bugs were waiting for
signoff (bug 16554 and bug 16573). They have not been tested yet and
they block the support of Ubuntu 16.04.

A dev meeting is planned on the 13 July
(https://wiki.koha-community.org/wiki/Development_IRC_meeting_13_July_2016).
Please have a look at the agenda and the different topics we will discuss.

Don't forget to register for the Hackfest in Marseille in October
(http://lists.koha-community.org/pipermail/koha-devel/2016-June/042790.html)!

Cheers,
Jonathan

From arslanone at gmail.com  Sun Jul 10 09:25:51 2016
From: arslanone at gmail.com (Arslan Farooq)
Date: Sun, 10 Jul 2016 12:25:51 +0500
Subject: [Koha-devel] [Koha] Introducing "Mana" (central DB project)
In-Reply-To: <577CD754.1090607@biblibre.com>
References: <577CD754.1090607@biblibre.com>
Message-ID: <CAFqgOiKsw_z5t3Fo3EHhFvkk16ocUJ838ySWOB0HfZuPHkV0Mw@mail.gmail.com>

Congratulations Paul, BibLibre, Morgane !

This will be great :-)

On Wed, Jul 6, 2016 at 3:03 PM, Paul Poulain <paul.poulain at biblibre.com>
wrote:

> Some months ago I sent an email to koha-devel, to announce that BibLibre
> was planning to work on a new project, dedicated to sharing informations
> between Koha (
> https://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc).
>
> I'm proud an happy to give you feedback about this project: things are
> moving quickly & nicely.
>
>  * *Morgane*, our intern -alex_a being the tutor) is doing a great job
> (you can congratulate her on #koha ;-) )
>  * we've named this project "*Mana*". It's a Maori word (once again :D),
> easy to pronounce & write.
> http://maoridictionary.co.nz/search?&keywords=mana : "*(verb)* to be
> legal, effectual, binding, authoritative, valid." I'll ask for
> mana.koha-community.org DNS entry soon !
>  * as announced by Morgane, we're using the same framework as for HEA for
> the server side. The code is available on our git:
> http://git.biblibre.com/biblibre/koha-mana (will be pushed later on
> git.koha-community.org). The DB is here, some webservice are already here
> & working.
>  * The koha-side is being worked, below are some screen shots.
>  * we changed some things compared to my initial RFC. Everything is on
> trello, splitted into cards (https://trello.com/b/BslL6i9p/mana-biblibre
> trello not public, claire, the owner is not here today, we'll change the
> status in a day or 2.) Note that there can be some French on trello, even
> if Morgane avoid it.
> We plan to have MANA working at the end of august, at least for
> subscriptions (pattern & numbering) sharing. Maybe also for SQL reports &
> vendors.
>
> Some screen shots & features descriptions:
>
>  in subscription management, you can now *share* a subscription pattern,
> by sending it to Mana:
>
> When you click on "share", after validation, you get a *feedback*:
>
>
>
> Anyone can then retrieve the numbering pattern & frequency calculation
> when creating a subscription (work being done this week). After the 1st
> screen of subscription creation, Koha will automatically query mana and
> check if there is some data available:
>
>
> The librarian will then be able to see what is available and get it
> locally in one click.
> Every time a librarian "get it locally", a counter will be incremented on
> Mana. Thus, if more than 1 frequency/pattern is submitted for a given
> title, the librarians should be able to see which one is "preferred" by
> other librarians.
>
> Additional features:
>  * we will create a script that will help populate Mana from a CSV. We
> will probably issue a RFF ("Request For File" ;-) ) later. Our idea is that
> we want to launch Mana with many data already available.
>  * comment. Any librarian will be able to add a comment to a shared data,
> as well as marking it as "obsolete".
>  * a syspref will be added to deactivate Mana (will be ON by default)
>
> Feel free to ask for more informations, I would be happy to answer !
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> 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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160710/23c2f392/attachment-0001.html>

From hagud at orex.es  Tue Jul 12 08:36:16 2016
From: hagud at orex.es (Hugo Agud)
Date: Tue, 12 Jul 2016 08:36:16 +0200
Subject: [Koha-devel] [Koha] Introducing "Mana" (central DB project)
In-Reply-To: <CA+QGetzL-xijqkg31kmULRmS=Q7sBBp1sZhpo3PHc6Pa9VMUKQ@mail.gmail.com>
References: <577CD754.1090607@biblibre.com>
	<CAFqgOiKsw_z5t3Fo3EHhFvkk16ocUJ838ySWOB0HfZuPHkV0Mw@mail.gmail.com>
	<CA+QGetzL-xijqkg31kmULRmS=Q7sBBp1sZhpo3PHc6Pa9VMUKQ@mail.gmail.com>
Message-ID: <CADT_QRQUATJWc+n80_-DXzhpcm=2um2ntZHH+fUcRW5fc6A3dw@mail.gmail.com>

Wonderful!!!

2016-07-11 23:20 GMT+02:00 Sebastian Hierl <s.hierl at aarome.org>:

> Congratulations and looking forward!
>
> Sebastian
> On Jul 10, 2016 9:26 AM, "Arslan Farooq" <arslanone at gmail.com> wrote:
>
> > Congratulations Paul, BibLibre, Morgane !
> >
> > This will be great :-)
> >
> > On Wed, Jul 6, 2016 at 3:03 PM, Paul Poulain <paul.poulain at biblibre.com>
> > wrote:
> >
> > > Some months ago I sent an email to koha-devel, to announce that
> BibLibre
> > > was planning to work on a new project, dedicated to sharing
> informations
> > > between Koha (
> > > https://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc).
> > >
> > > I'm proud an happy to give you feedback about this project: things are
> > > moving quickly & nicely.
> > >
> > >  * *Morgane*, our intern -alex_a being the tutor) is doing a great job
> > > (you can congratulate her on #koha ;-) )
> > >  * we've named this project "*Mana*". It's a Maori word (once again
> :D),
> > > easy to pronounce & write.
> > > http://maoridictionary.co.nz/search?&keywords=mana : "*(verb)* to be
> > > legal, effectual, binding, authoritative, valid." I'll ask for
> > > mana.koha-community.org DNS entry soon !
> > >  * as announced by Morgane, we're using the same framework as for HEA
> for
> > > the server side. The code is available on our git:
> > > http://git.biblibre.com/biblibre/koha-mana (will be pushed later on
> > > git.koha-community.org). The DB is here, some webservice are already
> > here
> > > & working.
> > >  * The koha-side is being worked, below are some screen shots.
> > >  * we changed some things compared to my initial RFC. Everything is on
> > > trello, splitted into cards (
> https://trello.com/b/BslL6i9p/mana-biblibre
> > > trello not public, claire, the owner is not here today, we'll change
> the
> > > status in a day or 2.) Note that there can be some French on trello,
> even
> > > if Morgane avoid it.
> > > We plan to have MANA working at the end of august, at least for
> > > subscriptions (pattern & numbering) sharing. Maybe also for SQL
> reports &
> > > vendors.
> > >
> > > Some screen shots & features descriptions:
> > >
> > >  in subscription management, you can now *share* a subscription
> pattern,
> > > by sending it to Mana:
> > >
> > > When you click on "share", after validation, you get a *feedback*:
> > >
> > >
> > >
> > > Anyone can then retrieve the numbering pattern & frequency calculation
> > > when creating a subscription (work being done this week). After the 1st
> > > screen of subscription creation, Koha will automatically query mana and
> > > check if there is some data available:
> > >
> > >
> > > The librarian will then be able to see what is available and get it
> > > locally in one click.
> > > Every time a librarian "get it locally", a counter will be incremented
> on
> > > Mana. Thus, if more than 1 frequency/pattern is submitted for a given
> > > title, the librarians should be able to see which one is "preferred" by
> > > other librarians.
> > >
> > > Additional features:
> > >  * we will create a script that will help populate Mana from a CSV. We
> > > will probably issue a RFF ("Request For File" ;-) ) later. Our idea is
> > that
> > > we want to launch Mana with many data already available.
> > >  * comment. Any librarian will be able to add a comment to a shared
> data,
> > > as well as marking it as "obsolete".
> > >  * a syspref will be added to deactivate Mana (will be ON by default)
> > >
> > > Feel free to ask for more informations, I would be happy to answer !
> > >
> > > --
> > > Paul Poulain, Associ?-g?rant / co-owner
> > > BibLibre, Services en logiciels libres pour les biblioth?ques
> > > BibLibre, Open Source software and services for libraries
> > >
> > > _______________________________________________
> > > Koha mailing list  http://koha-community.org
> > > Koha at lists.katipo.co.nz
> > > https://lists.katipo.co.nz/mailman/listinfo/koha
> > >
> > _______________________________________________
> > Koha mailing list  http://koha-community.org
> > Koha at lists.katipo.co.nz
> > https://lists.katipo.co.nz/mailman/listinfo/koha
> >
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>



-- 

*Hugo Agud - Orex Digital *

*www.orex.es <http://www.orex.es>*


<http://www.orex.es/>  [image: http://orex.es] <http://orex.es>
<http://www.orex.es>


Director

Passatge de la Llan?adera, 3 ? 08338 Premi? de Dalt - Tel: 93 539 40 70
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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160712/1538a614/attachment.html>

From oleonard at myacpl.org  Tue Jul 12 14:34:31 2016
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 12 Jul 2016 08:34:31 -0400
Subject: [Koha-devel] RFC: Retiring of the koha-patches mailing list
In-Reply-To: <CAEjTV=_BUz9t8=HY3=zFBFoEnS3MunV6zhd+Sq2QxYbbpz-eQw@mail.gmail.com>
References: <CAEjTV=_BUz9t8=HY3=zFBFoEnS3MunV6zhd+Sq2QxYbbpz-eQw@mail.gmail.com>
Message-ID: <CAO4qe2M44A37sP9E6UMewsyPjHcstw7-bkEJ7x=n3C2Az4c10g@mail.gmail.com>

> Does anyone have any strong objections to shutting down the mailing list?

+1 to shutting down the patches mailing list.

I haven't heard any objections yet, so let's move forward on it.

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From tomascohen at gmail.com  Tue Jul 12 14:45:21 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 12 Jul 2016 12:45:21 +0000
Subject: [Koha-devel] RFC: Retiring of the koha-patches mailing list
In-Reply-To: <CAO4qe2M44A37sP9E6UMewsyPjHcstw7-bkEJ7x=n3C2Az4c10g@mail.gmail.com>
References: <CAEjTV=_BUz9t8=HY3=zFBFoEnS3MunV6zhd+Sq2QxYbbpz-eQw@mail.gmail.com>
	<CAO4qe2M44A37sP9E6UMewsyPjHcstw7-bkEJ7x=n3C2Az4c10g@mail.gmail.com>
Message-ID: <CABZfb=VJ+cJJ9_t9QDF=p+myffcZ8o6+MUYowSK+XqR8Y4mRyw@mail.gmail.com>

+1

El mar., 12 jul. 2016 a las 9:34, Owen Leonard (<oleonard at myacpl.org>)
escribi?:

> > Does anyone have any strong objections to shutting down the mailing list?
>
> +1 to shutting down the patches mailing list.
>
> I haven't heard any objections yet, so let's move forward on it.
>
>   -- Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160712/e1145d2f/attachment.html>

From M.de.Rooy at rijksmuseum.nl  Tue Jul 12 15:00:22 2016
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Tue, 12 Jul 2016 13:00:22 +0000
Subject: [Koha-devel] RFC: Retiring of the koha-patches mailing list
In-Reply-To: <CABZfb=VJ+cJJ9_t9QDF=p+myffcZ8o6+MUYowSK+XqR8Y4mRyw@mail.gmail.com>
References: <CAEjTV=_BUz9t8=HY3=zFBFoEnS3MunV6zhd+Sq2QxYbbpz-eQw@mail.gmail.com>
	<CAO4qe2M44A37sP9E6UMewsyPjHcstw7-bkEJ7x=n3C2Az4c10g@mail.gmail.com>,
	<CABZfb=VJ+cJJ9_t9QDF=p+myffcZ8o6+MUYowSK+XqR8Y4mRyw@mail.gmail.com>
Message-ID: <VI1PR0501MB2591E4AE944895A184B41FAFCE300@VI1PR0501MB2591.eurprd05.prod.outlook.com>

+1

________________________________
Van: koha-devel-bounces at lists.koha-community.org <koha-devel-bounces at lists.koha-community.org> namens Tomas Cohen Arazi <tomascohen at gmail.com>
Verzonden: dinsdag 12 juli 2016 14:45:21
Aan: Owen Leonard; koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] RFC: Retiring of the koha-patches mailing list

+1

El mar., 12 jul. 2016 a las 9:34, Owen Leonard (<oleonard at myacpl.org<mailto:oleonard at myacpl.org>>) escribi?:
> Does anyone have any strong objections to shutting down the mailing list?

+1 to shutting down the patches mailing list.

I haven't heard any objections yet, so let's move forward on it.

  -- Owen

--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org<mailto:Koha-devel at lists.koha-community.org>
http://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 (https://theke.io<http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160712/87e35853/attachment.html>

From paul.poulain at biblibre.com  Tue Jul 12 18:43:30 2016
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 12 Jul 2016 18:43:30 +0200
Subject: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE
	performance issue !
Message-ID: <57851E32.5000202@biblibre.com>

Hi all,

Those days, we're working on a pretty large DB ( >1M biblio), for a 
customer that want to do many statistics on some fields.
We discovered that something "simple" like:
SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY 
publicationyear;

was giving *no result in 10mn*.
This is a test DB, not optimized, but we were surprised by the results.
After investigating we had the idea to create a biblioitems2 table with 
the same structure *EXCEPT MARCXML and MARC fields

*launch the same SQL query : *result in 3seconds* !*
*This could be reproduced on any query (on fields without index).

I think it's because the innoDB is storing each line in one "object", 
so, even if you need only one column, you have to read everything.
In our case, that was 12GB+ of data to read.
biblioitems2 is just a few dozen MB.
(all caching values are minimum and there's no index, so not involved in 
the results)

MY CONCLUSIONS:
  * the biblioitems.marc field must be removed quickly: it's useless 
since years, and is only resulting in slowing things
  * the bilbioitems.marcxml field should be moved outside from this 
table. Something like biblio_blob, with biblionumber, biblioitemnumber 
and marcxml. When we need it, just join the tables.

I'm almost sure it would have an important impact on Koha, as 
biblioitems table is called and used "everywhere".

any opinion ?
**

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries

-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160712/c45d8b59/attachment.html>

From tomascohen at gmail.com  Tue Jul 12 19:11:36 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 12 Jul 2016 17:11:36 +0000
Subject: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE
 performance issue !
In-Reply-To: <57851E32.5000202@biblibre.com>
References: <57851E32.5000202@biblibre.com>
Message-ID: <CABZfb=UfQY9uvOv=QsHMGteC_1VfbhJh62Tg2fNsRHPzMBFmaQ@mail.gmail.com>

I agree 100%, but I'd go for a metadata_record table with schema, (id),
biblionumber, format and metadata columns to start supporting more and more
schemas. Example:

| id | format     | schema | metadata
| 1  | marcxml | marc21  | ...
| 2  | usmarc   | unimarc | ...
| 3  | mij          | marc21  | ...

pretty much like we do with Koha::MetadataRecord actually :-D

Nice catch, Paul!



El mar., 12 jul. 2016 a las 13:43, Paul Poulain (<paul.poulain at biblibre.com>)
escribi?:

> Hi all,
>
> Those days, we're working on a pretty large DB ( >1M biblio), for a
> customer that want to do many statistics on some fields.
> We discovered that something "simple" like:
> SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY
> publicationyear;
>
> was giving *no result in 10mn*.
> This is a test DB, not optimized, but we were surprised by the results.
> After investigating we had the idea to create a biblioitems2 table with
> the same structure
>
> *EXCEPT MARCXML and MARC fields *launch the same SQL query : *result in
> 3seconds* !
> This could be reproduced on any query (on fields without index).
>
> I think it's because the innoDB is storing each line in one "object", so,
> even if you need only one column, you have to read everything.
> In our case, that was 12GB+ of data to read.
> biblioitems2 is just a few dozen MB.
> (all caching values are minimum and there's no index, so not involved in
> the results)
>
> MY CONCLUSIONS:
>  * the biblioitems.marc field must be removed quickly: it's useless since
> years, and is only resulting in slowing things
>  * the bilbioitems.marcxml field should be moved outside from this table.
> Something like biblio_blob, with biblionumber, biblioitemnumber and
> marcxml. When we need it, just join the tables.
>
> I'm almost sure it would have an important impact on Koha, as biblioitems
> table is called and used "everywhere".
>
> any opinion ?
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160712/3583988d/attachment-0001.html>

From Katrin.Fischer.83 at web.de  Tue Jul 12 19:41:19 2016
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Tue, 12 Jul 2016 19:41:19 +0200
Subject: [Koha-devel] RFC: Retiring of the koha-patches mailing list
In-Reply-To: <VI1PR0501MB2591E4AE944895A184B41FAFCE300@VI1PR0501MB2591.eurprd05.prod.outlook.com>
References: <CAEjTV=_BUz9t8=HY3=zFBFoEnS3MunV6zhd+Sq2QxYbbpz-eQw@mail.gmail.com>
	<CAO4qe2M44A37sP9E6UMewsyPjHcstw7-bkEJ7x=n3C2Az4c10g@mail.gmail.com>
	<CABZfb=VJ+cJJ9_t9QDF=p+myffcZ8o6+MUYowSK+XqR8Y4mRyw@mail.gmail.com>
	<VI1PR0501MB2591E4AE944895A184B41FAFCE300@VI1PR0501MB2591.eurprd05.prod.outlook.com>
Message-ID: <57852BBF.6030404@web.de>

Already +1'ed this some time ago :)

Who can make it happen?

Am 12.07.2016 um 15:00 schrieb Marcel de Rooy:
> +1
> 
> ------------------------------------------------------------------------
> *Van:* koha-devel-bounces at lists.koha-community.org
> <koha-devel-bounces at lists.koha-community.org> namens Tomas Cohen Arazi
> <tomascohen at gmail.com>
> *Verzonden:* dinsdag 12 juli 2016 14:45:21
> *Aan:* Owen Leonard; koha-devel at lists.koha-community.org
> *Onderwerp:* Re: [Koha-devel] RFC: Retiring of the koha-patches mailing
> list
>  
> +1
> 
> El mar., 12 jul. 2016 a las 9:34, Owen Leonard (<oleonard at myacpl.org
> <mailto:oleonard at myacpl.org>>) escribi?:
> 
>     > Does anyone have any strong objections to shutting down the
>     mailing list?
> 
>     +1 to shutting down the patches mailing list.
> 
>     I haven't heard any objections yet, so let's move forward on it.
> 
>       -- Owen
> 
>     --
>     Web Developer
>     Athens County Public Libraries
>     http://www.myacpl.org
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at lists.koha-community.org>
>     http://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 (https://theke.io <http://theke.io/>)
> ? +54 9351 3513384
> GPG: B2F3C15F
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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  Tue Jul 12 19:49:45 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Tue, 12 Jul 2016 18:49:45 +0100
Subject: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE
 performance issue !
In-Reply-To: <57851E32.5000202@biblibre.com>
References: <57851E32.5000202@biblibre.com>
Message-ID: <CAJzKNY7Kv-FSU=mT1O3VrBJM3Nwv75zpLYUV-Z81NY4xq3iHhA@mail.gmail.com>

2016-07-12 17:43 GMT+01:00 Paul Poulain <paul.poulain at biblibre.com>:
> Hi all,

Hi Paul,

> Those days, we're working on a pretty large DB ( >1M biblio), for a customer
> that want to do many statistics on some fields.
> We discovered that something "simple" like:
> SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY
> publicationyear;
>
> was giving no result in 10mn.
> This is a test DB, not optimized, but we were surprised by the results.
> After investigating we had the idea to create a biblioitems2 table with the
> same structure EXCEPT MARCXML and MARC fields
>
> launch the same SQL query : result in 3seconds !
> This could be reproduced on any query (on fields without index).
>
> I think it's because the innoDB is storing each line in one "object", so,
> even if you need only one column, you have to read everything.
> In our case, that was 12GB+ of data to read.
> biblioitems2 is just a few dozen MB.
> (all caching values are minimum and there's no index, so not involved in the
> results)
>
> MY CONCLUSIONS:
>  * the biblioitems.marc field must be removed quickly: it's useless since
> years, and is only resulting in slowing things

Yep, see bug 10455 and argue in this direction :) I am just waiting
for a go to submit a patch (I have already some changes on a old local
branch).

>  * the bilbioitems.marcxml field should be moved outside from this table.
> Something like biblio_blob, with biblionumber, biblioitemnumber and marcxml.
> When we need it, just join the tables.
>
> I'm almost sure it would have an important impact on Koha, as biblioitems
> table is called and used "everywhere".

Let's remove biblioitems?
Ok it won't fix the issue, but let's remove it anyway :p

> any opinion ?

Did you test the same structure removing marcxml only and then
removing marc only?
Just out of curiosity :)

> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 Katrin.Fischer.83 at web.de  Tue Jul 12 19:50:15 2016
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Tue, 12 Jul 2016 19:50:15 +0200
Subject: [Koha-devel] Reminder: Koha Developer IRC Meeting - 13 July 2016,
	14 UTC
Message-ID: <57852DD7.3090002@web.de>

Hi all,

just sending a quick meeting reminder:

https://wiki.koha-community.org/wiki/Development_IRC_meeting_13_July_2016

Please take a look at the agenda and add any topics that you want to
discuss in advance of the meeting.

See you there!

Katrin

From chrisc at catalyst.net.nz  Tue Jul 12 20:42:35 2016
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 13 Jul 2016 06:42:35 +1200
Subject: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE
	performance issue !
In-Reply-To: <CABZfb=UfQY9uvOv=QsHMGteC_1VfbhJh62Tg2fNsRHPzMBFmaQ@mail.gmail.com>
References: <57851E32.5000202@biblibre.com>
	<CABZfb=UfQY9uvOv=QsHMGteC_1VfbhJh62Tg2fNsRHPzMBFmaQ@mail.gmail.com>
Message-ID: <7FD0A0EE-B776-40E9-9B3B-9BC1A7E1571F@catalyst.net.nz>

+1 from me

On 13 July 2016 5:11:36 AM NZST, Tomas Cohen Arazi <tomascohen at gmail.com> wrote:
>I agree 100%, but I'd go for a metadata_record table with schema, (id),
>biblionumber, format and metadata columns to start supporting more and
>more
>schemas. Example:
>
>| id | format     | schema | metadata
>| 1  | marcxml | marc21  | ...
>| 2  | usmarc   | unimarc | ...
>| 3  | mij          | marc21  | ...
>
>pretty much like we do with Koha::MetadataRecord actually :-D
>
>Nice catch, Paul!
>
>
>
>El mar., 12 jul. 2016 a las 13:43, Paul Poulain
>(<paul.poulain at biblibre.com>)
>escribi?:
>
>> Hi all,
>>
>> Those days, we're working on a pretty large DB ( >1M biblio), for a
>> customer that want to do many statistics on some fields.
>> We discovered that something "simple" like:
>> SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP
>BY
>> publicationyear;
>>
>> was giving *no result in 10mn*.
>> This is a test DB, not optimized, but we were surprised by the
>results.
>> After investigating we had the idea to create a biblioitems2 table
>with
>> the same structure
>>
>> *EXCEPT MARCXML and MARC fields *launch the same SQL query : *result
>in
>> 3seconds* !
>> This could be reproduced on any query (on fields without index).
>>
>> I think it's because the innoDB is storing each line in one "object",
>so,
>> even if you need only one column, you have to read everything.
>> In our case, that was 12GB+ of data to read.
>> biblioitems2 is just a few dozen MB.
>> (all caching values are minimum and there's no index, so not involved
>in
>> the results)
>>
>> MY CONCLUSIONS:
>>  * the biblioitems.marc field must be removed quickly: it's useless
>since
>> years, and is only resulting in slowing things
>>  * the bilbioitems.marcxml field should be moved outside from this
>table.
>> Something like biblio_blob, with biblionumber, biblioitemnumber and
>> marcxml. When we need it, just join the tables.
>>
>> I'm almost sure it would have an important impact on Koha, as
>biblioitems
>> table is called and used "everywhere".
>>
>> any opinion ?
>>
>> --
>> Paul Poulain, Associ?-g?rant / co-owner
>> BibLibre, Services en logiciels libres pour les biblioth?ques
>> BibLibre, Open Source software and services for libraries
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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 (https://theke.io <http://theke.io/>)
>? +54 9351 3513384
>GPG: B2F3C15F
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Koha-devel mailing list
>Koha-devel at lists.koha-community.org
>http://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/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/ae493a64/attachment.html>

From dcook at prosentient.com.au  Wed Jul 13 03:51:45 2016
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 13 Jul 2016 11:51:45 +1000
Subject: [Koha-devel] biblioitems.marcxml & biblioitems.marc /
	HUGE	performance issue !
In-Reply-To: <7FD0A0EE-B776-40E9-9B3B-9BC1A7E1571F@catalyst.net.nz>
References: <57851E32.5000202@biblibre.com>	<CABZfb=UfQY9uvOv=QsHMGteC_1VfbhJh62Tg2fNsRHPzMBFmaQ@mail.gmail.com>
	<7FD0A0EE-B776-40E9-9B3B-9BC1A7E1571F@catalyst.net.nz>
Message-ID: <009201d1dca9$1c3b3100$54b19300$@prosentient.com.au>

+1 from me too

 

It?ll hopefully go a long way to moving away from MARC in the long-term too?

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Chris Cormack
Sent: Wednesday, 13 July 2016 4:43 AM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] biblioitems.marcxml & biblioitems.marc / HUGE performance issue !

 

+1 from me

On 13 July 2016 5:11:36 AM NZST, Tomas Cohen Arazi <tomascohen at gmail.com <mailto:tomascohen at gmail.com> > wrote:

I agree 100%, but I'd go for a metadata_record table with schema, (id), biblionumber, format and metadata columns to start supporting more and more schemas. Example:

 

| id | format     | schema | metadata

| 1  | marcxml | marc21  | ... 

| 2  | usmarc   | unimarc | ...

| 3  | mij          | marc21  | ...

 

pretty much like we do with Koha::MetadataRecord actually :-D

 

Nice catch, Paul!

 

 

 

El mar., 12 jul. 2016 a las 13:43, Paul Poulain (<paul.poulain at biblibre.com <mailto:paul.poulain at biblibre.com> >) escribi?:

Hi all,

Those days, we're working on a pretty large DB ( >1M biblio), for a customer that want to do many statistics on some fields.
We discovered that something "simple" like:
SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY publicationyear;

was giving no result in 10mn.
This is a test DB, not optimized, but we were surprised by the results.
After investigating we had the idea to create a biblioitems2 table with the same structure EXCEPT MARCXML and MARC fields

launch the same SQL query : result in 3seconds !
This could be reproduced on any query (on fields without index).

I think it's because the innoDB is storing each line in one "object", so, even if you need only one column, you have to read everything.
In our case, that was 12GB+ of data to read.
biblioitems2 is just a few dozen MB.
(all caching values are minimum and there's no index, so not involved in the results)

MY CONCLUSIONS:
 * the biblioitems.marc field must be removed quickly: it's useless since years, and is only resulting in slowing things
 * the bilbioitems.marcxml field should be moved outside from this table. Something like biblio_blob, with biblionumber, biblioitemnumber and marcxml. When we need it, just join the tables.

I'm almost sure it would have an important impact on Koha, as biblioitems table is called and used "everywhere".

any opinion ?



-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://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 (https://theke.io <http://theke.io/> )
? +54 9351 3513384
GPG: B2F3C15F



  _____  


Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://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/


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/70d817d3/attachment-0001.html>

From dcook at prosentient.com.au  Wed Jul 13 03:58:33 2016
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 13 Jul 2016 11:58:33 +1000
Subject: [Koha-devel] Permissions for /var/spool/koha/instance and possible
	path changes
Message-ID: <009701d1dcaa$0fc3db60$2f4b9220$@prosentient.com.au>

Hi all,

 

I was just reviewing the Filesystem Hierarchy Standard, and it's led me to
think that the package backups should be written to /var/lib/koha rather
than /var/spool/koha.

 

Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and
http://www.pathname.com/fhs/2.2/fhs-5.14.html

 

I say this because I want to make use of /var/spool/koha/instance/X to store
data for later processing, but notice that /var/spool/koha/instance can only
be written to by root, and thus is inaccessible to the Koha user. 

 

So I figure that we should make /var/spool/koha/instance owned by the Koha
user and just have backups owned by root like usual. That would solve the
issue.

 

But on top of that. I'm wondering if we should be using
/var/lib/koha/instance/backups for storing the SQL and config backups. I'm
open to other ideas, but backups don't really seem like spooled data to  me.


 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/230efc61/attachment.html>

From reed at typist.geek.nz  Wed Jul 13 04:09:02 2016
From: reed at typist.geek.nz (Reed Wade)
Date: Wed, 13 Jul 2016 14:09:02 +1200
Subject: [Koha-devel] Permissions for /var/spool/koha/instance and
 possible path changes
In-Reply-To: <009701d1dcaa$0fc3db60$2f4b9220$@prosentient.com.au>
References: <009701d1dcaa$0fc3db60$2f4b9220$@prosentient.com.au>
Message-ID: <CAMjHDpS+8-OKqsuR8hrdsz_tzwTsoyFJE4zpueowM+MgSGqrzQ@mail.gmail.com>

opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html

code in /opt/koha and data in /var/opt/koha

We've been using this pattern at the place I just left (not for Koha but
other things) and it makes it very easy and (for us at least was--your
mileage will vary) intuitive.

--

side note-- /var/opt instead of /opt/var allows you to keep a var-like disk
management strategy for all of /var without having to make it a special
case.

-reed



On 13 July 2016 at 13:58, David Cook <dcook at prosentient.com.au> wrote:

> Hi all,
>
>
>
> I was just reviewing the Filesystem Hierarchy Standard, and it?s led me to
> think that the package backups should be written to /var/lib/koha rather
> than /var/spool/koha.
>
>
>
> Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and
> http://www.pathname.com/fhs/2.2/fhs-5.14.html
>
>
>
> I say this because I want to make use of /var/spool/koha/instance/X to
> store data for later processing, but notice that /var/spool/koha/instance
> can only be written to by root, and thus is inaccessible to the Koha user.
>
>
>
> So I figure that we should make /var/spool/koha/instance owned by the Koha
> user and just have backups owned by root like usual. That would solve the
> issue.
>
>
>
> But on top of that? I?m wondering if we should be using
> /var/lib/koha/instance/backups for storing the SQL and config backups. I?m
> open to other ideas, but backups don?t really seem like spooled data to
> me.
>
>
>
> David Cook
>
> Systems Librarian
>
>
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
>
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/d26f862d/attachment.html>

From dcook at prosentient.com.au  Wed Jul 13 04:13:46 2016
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 13 Jul 2016 12:13:46 +1000
Subject: [Koha-devel] Permissions for /var/spool/koha/instance and
	possible path changes
In-Reply-To: <CAMjHDpS+8-OKqsuR8hrdsz_tzwTsoyFJE4zpueowM+MgSGqrzQ@mail.gmail.com>
References: <009701d1dcaa$0fc3db60$2f4b9220$@prosentient.com.au>
	<CAMjHDpS+8-OKqsuR8hrdsz_tzwTsoyFJE4zpueowM+MgSGqrzQ@mail.gmail.com>
Message-ID: <009e01d1dcac$2fa89cc0$8ef9d640$@prosentient.com.au>

That?s an option for folk doing tarball installs, but I?m thinking for the Debian packages, which already have a set way of doing things (like code in /usr/share/koha, etc).

 

To be honest, I?ve been thinking a bit about making RPM packages for Koha and thinking about where I?d put all the files? I?d probably want to emulate the Debian layout as much as possible to reuse scripts with hard-coded values. Of course, I probably won?t make an official RPM for Koha since managing the Perl dependencies on a non-Debian system is impossible using the distro?s package manager alone?

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Reed Wade [mailto:reed at typist.geek.nz] 
Sent: Wednesday, 13 July 2016 12:09 PM
To: David Cook <dcook at prosentient.com.au>
Cc: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes

 

 

opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html

 

code in /opt/koha and data in /var/opt/koha

 

We've been using this pattern at the place I just left (not for Koha but other things) and it makes it very easy and (for us at least was--your mileage will vary) intuitive.

 

--

 

side note-- /var/opt instead of /opt/var allows you to keep a var-like disk management strategy for all of /var without having to make it a special case.

 

-reed

 

 

 

On 13 July 2016 at 13:58, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:

Hi all,

 

I was just reviewing the Filesystem Hierarchy Standard, and it?s led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha.

 

Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html

 

I say this because I want to make use of /var/spool/koha/instance/X to store data for later processing, but notice that /var/spool/koha/instance can only be written to by root, and thus is inaccessible to the Koha user. 

 

So I figure that we should make /var/spool/koha/instance owned by the Koha user and just have backups owned by root like usual. That would solve the issue.

 

But on top of that? I?m wondering if we should be using /var/lib/koha/instance/backups for storing the SQL and config backups. I?m open to other ideas, but backups don?t really seem like spooled data to  me. 

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/328a090c/attachment-0001.html>

From dcook at prosentient.com.au  Wed Jul 13 04:14:48 2016
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 13 Jul 2016 12:14:48 +1000
Subject: [Koha-devel] Permissions for /var/spool/koha/instance and
	possible path changes
In-Reply-To: <CAMjHDpS+8-OKqsuR8hrdsz_tzwTsoyFJE4zpueowM+MgSGqrzQ@mail.gmail.com>
References: <009701d1dcaa$0fc3db60$2f4b9220$@prosentient.com.au>
	<CAMjHDpS+8-OKqsuR8hrdsz_tzwTsoyFJE4zpueowM+MgSGqrzQ@mail.gmail.com>
Message-ID: <00a301d1dcac$5515e940$ff41bbc0$@prosentient.com.au>

P.S. In general, I quite like /opt/X for code. I?ve been working more on Redhat lately, and I?ve noticed that Redhat uses /opt for their Redhat Software Collection packages. Not sure how common it is to use in the packaging world though.

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Reed Wade [mailto:reed at typist.geek.nz] 
Sent: Wednesday, 13 July 2016 12:09 PM
To: David Cook <dcook at prosentient.com.au>
Cc: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes

 

 

opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html

 

code in /opt/koha and data in /var/opt/koha

 

We've been using this pattern at the place I just left (not for Koha but other things) and it makes it very easy and (for us at least was--your mileage will vary) intuitive.

 

--

 

side note-- /var/opt instead of /opt/var allows you to keep a var-like disk management strategy for all of /var without having to make it a special case.

 

-reed

 

 

 

On 13 July 2016 at 13:58, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:

Hi all,

 

I was just reviewing the Filesystem Hierarchy Standard, and it?s led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha.

 

Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html

 

I say this because I want to make use of /var/spool/koha/instance/X to store data for later processing, but notice that /var/spool/koha/instance can only be written to by root, and thus is inaccessible to the Koha user. 

 

So I figure that we should make /var/spool/koha/instance owned by the Koha user and just have backups owned by root like usual. That would solve the issue.

 

But on top of that? I?m wondering if we should be using /var/lib/koha/instance/backups for storing the SQL and config backups. I?m open to other ideas, but backups don?t really seem like spooled data to  me. 

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/ccd0ddf7/attachment.html>

From dcook at prosentient.com.au  Wed Jul 13 05:47:06 2016
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 13 Jul 2016 13:47:06 +1000
Subject: [Koha-devel] Using the file upload feature for
	more	customization
In-Reply-To: <CAMSJbVsGB-otaxW2Zs+Qjw=DiuEKB7gVXsoYihsrK+7-wktQFg@mail.gmail.com>
References: <CAO4qe2N3CHrPAYVhWnhH39=poQBhO_dbsdi+RG2mLZ-wKsfBrg@mail.gmail.com>
	<CAMSJbVsGB-otaxW2Zs+Qjw=DiuEKB7gVXsoYihsrK+7-wktQFg@mail.gmail.com>
Message-ID: <00aa01d1dcb9$398df480$aca9dd80$@prosentient.com.au>

In regards to XSLTs, I?d love some sort of registry where you could add XSLTs and then reference them elsewhere from a dropdown. 

 

As for  <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648, I?m curious why we?d have XSLTs publicly accessible. If you?re referencing ?cgi-bin/koha/xslt/OPACXSLTResultsDisplay.xslt?, then anyone can come along and read what you have in your XSLT. I suppose Koha is open source, so that?s not really the end of the world, but it just seems odd to be allowing public access to that asset when you?re using it on the server. Why fetch it via Apache when you already have it on your system? Unless you?re getting a XSLT from some other server? but then it?s a separate issue.

 

But yeah. I like the idea of a registry? where you could choose XSLTs for the Z39.50 filtering, MARCXML->HTML display, exports, etc. I?m doing OAI-PMH imports right now and I want to filter using XSLT, but it?s painful for library users to define these XSLT filepaths. There should be a simple option for users who aren?t developers/sysadmins.

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Barton Chittenden
Sent: Wednesday, 15 June 2016 12:20 AM
To: Owen Leonard <oleonard at myacpl.org>
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Using the file upload feature for more customization

 

Owen,

 

I've been wrestling with the issue of CSS and XSLT as well, my proposed solution is

 

Add Content system preferences for all CSS and XSLT sysprefs that accept a URL. ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648 )

 

that should be relatively easy to implement, simply because we can re-use code from sysprefs like intranetuserjs.

 

I do like the idea of a flexible file uploader though; it's definitely more flexible...

 

 

 

On Tue, Jun 14, 2016 at 9:31 AM, Owen Leonard <oleonard at myacpl.org <mailto:oleonard at myacpl.org> > wrote:

Now that there is a generic file upload tool, could that be used to
offer more customization options in areas where file selections are
used? I'm imagining a system where you define upload categories: CSS,
image, audio file, XSLT. Then wherever a setting allows you to select
a file in that category Koha would list your uploaded files as
options.

Currently it's a problem for libraries who want to define their own
set of item type icons or load a separate CSS file: Where does the
file go?

I just wanted to throw that idea out there in case it sounded
interesting to someone.

  -- Owen

--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/e8b9311d/attachment-0001.html>

From barton at bywatersolutions.com  Wed Jul 13 07:18:13 2016
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Wed, 13 Jul 2016 01:18:13 -0400
Subject: [Koha-devel] Using the file upload feature for more
	customization
In-Reply-To: <00aa01d1dcb9$398df480$aca9dd80$@prosentient.com.au>
References: <CAO4qe2N3CHrPAYVhWnhH39=poQBhO_dbsdi+RG2mLZ-wKsfBrg@mail.gmail.com>
	<CAMSJbVsGB-otaxW2Zs+Qjw=DiuEKB7gVXsoYihsrK+7-wktQFg@mail.gmail.com>
	<00aa01d1dcb9$398df480$aca9dd80$@prosentient.com.au>
Message-ID: <CAMSJbVvbydNNRFndDVPHFsA1ar0si=_c2fYLuoGzzAGQ+LMqSQ@mail.gmail.com>

On Jul 12, 2016 11:47 PM, "David Cook" <dcook at prosentient.com.au> wrote:
>
> In regards to XSLTs, I?d love some sort of registry where you could add
XSLTs and then reference them elsewhere from a dropdown.
>
>
>
> As for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648,
I?m curious why we?d have XSLTs publicly accessible. If you?re referencing
?cgi-bin/koha/xslt/OPACXSLTResultsDisplay.xslt?, then anyone can come along
and read what you have in your XSLT. I suppose Koha is open source, so
that?s not really the end of the world, but it just seems odd to be
allowing public access to that asset when you?re using it on the server.
Why fetch it via Apache when you already have it on your system? Unless
you?re getting a XSLT from some other server? but then it?s a separate
issue.

Hmm. I hadn't really considered that the XSLTs *should* be private -- my
consideration is that there is a pain point of having XSLTs as files -- how
do you make sure that custom XSLT files move with an instance  on server
upgrade? Where should the files reside on an instance by instance basis?

Right now, the XSLT files are stored in  the main git repo, or are
installed globally. Tracking customized xslt across tens or hundreds of
instances is no fun, and xslt errors can be hard to trouble shoot (in the
case of a mis versioneed xslt file) if you're not expecting them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/fea7b8df/attachment.html>

From dcook at prosentient.com.au  Wed Jul 13 07:27:09 2016
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 13 Jul 2016 15:27:09 +1000
Subject: [Koha-devel] Using the file upload feature for more
	customization
In-Reply-To: <CAMSJbVvbydNNRFndDVPHFsA1ar0si=_c2fYLuoGzzAGQ+LMqSQ@mail.gmail.com>
References: <CAO4qe2N3CHrPAYVhWnhH39=poQBhO_dbsdi+RG2mLZ-wKsfBrg@mail.gmail.com>	<CAMSJbVsGB-otaxW2Zs+Qjw=DiuEKB7gVXsoYihsrK+7-wktQFg@mail.gmail.com>	<00aa01d1dcb9$398df480$aca9dd80$@prosentient.com.au>
	<CAMSJbVvbydNNRFndDVPHFsA1ar0si=_c2fYLuoGzzAGQ+LMqSQ@mail.gmail.com>
Message-ID: <00bf01d1dcc7$33afd8e0$9b0f8aa0$@prosentient.com.au>

Hi Barton,

 

You?re referring to your local Bywater practice, yes?

 

By default, users would be using the XSLTs installed with their Koha (Deb packages or source install), so the default XSLTs would be registered using the filepath on the local server, I reckon. I suppose if you were to use HTTP, you could specify that in the registry as well, so I wouldn?t imagine it being a problem. The registry would just give you a user friendly name instead of a file or HTTP URL, and allow you to address it easily from anywhere in Koha.

 

As for my local practice, we don?t maintain customized XSLTs much. We either use the default one packaged with Koha, or use a single customized one that we maintain per Koha version (rather than per client), and we use Local system preferences for the really specific stuff. But that?s just a different commercial practice.

 

The registry should be able to handle either scenario : ).

 

David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Barton Chittenden [mailto:barton at bywatersolutions.com] 
Sent: Wednesday, 13 July 2016 3:18 PM
To: David Cook <dcook at prosentient.com.au>
Cc: Koha-devel <koha-devel at lists.koha-community.org>; Tomas Cohen Arazi <tomascohen at gmail.com>; Owen Leonard <oleonard at myacpl.org>
Subject: RE: [Koha-devel] Using the file upload feature for more customization

 


On Jul 12, 2016 11:47 PM, "David Cook" <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:
>
> In regards to XSLTs, I?d love some sort of registry where you could add XSLTs and then reference them elsewhere from a dropdown.
>
>  
>
> As for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648, I?m curious why we?d have XSLTs publicly accessible. If you?re referencing ?cgi-bin/koha/xslt/OPACXSLTResultsDisplay.xslt?, then anyone can come along and read what you have in your XSLT. I suppose Koha is open source, so that?s not really the end of the world, but it just seems odd to be allowing public access to that asset when you?re using it on the server. Why fetch it via Apache when you already have it on your system? Unless you?re getting a XSLT from some other server? but then it?s a separate issue.

Hmm. I hadn't really considered that the XSLTs *should* be private -- my consideration is that there is a pain point of having XSLTs as files -- how do you make sure that custom XSLT files move with an instance  on server upgrade? Where should the files reside on an instance by instance basis?

Right now, the XSLT files are stored in  the main git repo, or are installed globally. Tracking customized xslt across tens or hundreds of instances is no fun, and xslt errors can be hard to trouble shoot (in the case of a mis versioneed xslt file) if you're not expecting them.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/454a6f3a/attachment.html>

From ikourmou at lib.auth.gr  Wed Jul 13 08:37:58 2016
From: ikourmou at lib.auth.gr (=?UTF-8?B?zpPOuc6szr3Ovc63z4IgzprOv8+Fz4HOvM6/z43Ou863z4I=?=)
Date: Wed, 13 Jul 2016 09:37:58 +0300
Subject: [Koha-devel] mailing list creation for greek koha community
Message-ID: <CAAMU9tcD-oYky4aXKZP=1cyw8qdq0OyTujHLTGLV5zbLNSQiMw@mail.gmail.com>

dear developers list

a month ago, I sent the following mail to mailman at lists.koha-community.org.

-----
-Dear administrators
-
-as we are trying to establish the Greek Koha Users Group, we would also
like to create the Greek koha users mailing list. I understand that we
-need a "List creator's (authentication) password". Could you provide it?
-
-thank you
?-----

?I have not received any response since. ?If any administrator of the koha
mailing lists sees this, please respond...

thank you

-------------------------------------------------------------
??????? ??????????
?????????? ??? ?????? ???????????? ?.?.?.
????? ???????? ???????????
???: 2310995368
Fax: 2310995364

-|Giannis Kourmoulis
-|Library and Information Centre A.U.Th.
-|Technical Support Team
-|Tel: +302310995368
-|Fax: +302310995364

email:libsupport at lib.auth.gr
-------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/0482924b/attachment.html>

From kyle.m.hall at gmail.com  Wed Jul 13 15:37:49 2016
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Wed, 13 Jul 2016 09:37:49 -0400
Subject: [Koha-devel] RFC: Retiring of the koha-patches mailing list
In-Reply-To: <57852BBF.6030404@web.de>
References: <CAEjTV=_BUz9t8=HY3=zFBFoEnS3MunV6zhd+Sq2QxYbbpz-eQw@mail.gmail.com>
	<CAO4qe2M44A37sP9E6UMewsyPjHcstw7-bkEJ7x=n3C2Az4c10g@mail.gmail.com>
	<CABZfb=VJ+cJJ9_t9QDF=p+myffcZ8o6+MUYowSK+XqR8Y4mRyw@mail.gmail.com>
	<VI1PR0501MB2591E4AE944895A184B41FAFCE300@VI1PR0501MB2591.eurprd05.prod.outlook.com>
	<57852BBF.6030404@web.de>
Message-ID: <CACpVHfxaDtm3c4gyq4GsLLzsYCBbvCoBXvzBBWOPxh-q1ag1gg@mail.gmail.com>

I suppose the question is who has the power to do this?

Kyle

<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>

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 Tue, Jul 12, 2016 at 1:41 PM, Katrin Fischer <Katrin.Fischer.83 at web.de>
wrote:

> Already +1'ed this some time ago :)
>
> Who can make it happen?
>
> Am 12.07.2016 um 15:00 schrieb Marcel de Rooy:
> > +1
> >
> > ------------------------------------------------------------------------
> > *Van:* koha-devel-bounces at lists.koha-community.org
> > <koha-devel-bounces at lists.koha-community.org> namens Tomas Cohen Arazi
> > <tomascohen at gmail.com>
> > *Verzonden:* dinsdag 12 juli 2016 14:45:21
> > *Aan:* Owen Leonard; koha-devel at lists.koha-community.org
> > *Onderwerp:* Re: [Koha-devel] RFC: Retiring of the koha-patches mailing
> > list
> >
> > +1
> >
> > El mar., 12 jul. 2016 a las 9:34, Owen Leonard (<oleonard at myacpl.org
> > <mailto:oleonard at myacpl.org>>) escribi?:
> >
> >     > Does anyone have any strong objections to shutting down the
> >     mailing list?
> >
> >     +1 to shutting down the patches mailing list.
> >
> >     I haven't heard any objections yet, so let's move forward on it.
> >
> >       -- Owen
> >
> >     --
> >     Web Developer
> >     Athens County Public Libraries
> >     http://www.myacpl.org
> >     _______________________________________________
> >     Koha-devel mailing list
> >     Koha-devel at lists.koha-community.org
> >     <mailto:Koha-devel at lists.koha-community.org>
> >     http://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 (https://theke.io <http://theke.io/>)
> > ? +54 9351 3513384
> > GPG: B2F3C15F
> >
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://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
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/880159e8/attachment.html>

From kyle.m.hall at gmail.com  Wed Jul 13 16:12:31 2016
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Wed, 13 Jul 2016 14:12:31 +0000
Subject: [Koha-devel] [Koha] Introducing "Mana" (central DB project)
In-Reply-To: <CADT_QRQUATJWc+n80_-DXzhpcm=2um2ntZHH+fUcRW5fc6A3dw@mail.gmail.com>
References: <577CD754.1090607@biblibre.com>
	<CAFqgOiKsw_z5t3Fo3EHhFvkk16ocUJ838ySWOB0HfZuPHkV0Mw@mail.gmail.com>
	<CA+QGetzL-xijqkg31kmULRmS=Q7sBBp1sZhpo3PHc6Pa9VMUKQ@mail.gmail.com>
	<CADT_QRQUATJWc+n80_-DXzhpcm=2um2ntZHH+fUcRW5fc6A3dw@mail.gmail.com>
Message-ID: <CACpVHfwEZUHA4Mo9Twt5P=PKYo9o1Wts9Qx9MOY=irNGnuxQ3Q@mail.gmail.com>

Fantastic! I look forward to seeing what we can share with this!

Kyle

On Tue, Jul 12, 2016 at 2:36 AM Hugo Agud <hagud at orex.es> wrote:

> Wonderful!!!
>
> 2016-07-11 23:20 GMT+02:00 Sebastian Hierl <s.hierl at aarome.org>:
>
>> Congratulations and looking forward!
>>
>> Sebastian
>> On Jul 10, 2016 9:26 AM, "Arslan Farooq" <arslanone at gmail.com> wrote:
>>
>> > Congratulations Paul, BibLibre, Morgane !
>> >
>> > This will be great :-)
>> >
>> > On Wed, Jul 6, 2016 at 3:03 PM, Paul Poulain <paul.poulain at biblibre.com
>> >
>> > wrote:
>> >
>> > > Some months ago I sent an email to koha-devel, to announce that
>> BibLibre
>> > > was planning to work on a new project, dedicated to sharing
>> informations
>> > > between Koha (
>> > > https://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc).
>> > >
>> > > I'm proud an happy to give you feedback about this project: things are
>> > > moving quickly & nicely.
>> > >
>> > >  * *Morgane*, our intern -alex_a being the tutor) is doing a great job
>> > > (you can congratulate her on #koha ;-) )
>> > >  * we've named this project "*Mana*". It's a Maori word (once again
>> :D),
>> > > easy to pronounce & write.
>> > > http://maoridictionary.co.nz/search?&keywords=mana : "*(verb)* to be
>> > > legal, effectual, binding, authoritative, valid." I'll ask for
>> > > mana.koha-community.org DNS entry soon !
>> > >  * as announced by Morgane, we're using the same framework as for HEA
>> for
>> > > the server side. The code is available on our git:
>> > > http://git.biblibre.com/biblibre/koha-mana (will be pushed later on
>> > > git.koha-community.org). The DB is here, some webservice are already
>> > here
>> > > & working.
>> > >  * The koha-side is being worked, below are some screen shots.
>> > >  * we changed some things compared to my initial RFC. Everything is on
>> > > trello, splitted into cards (
>> https://trello.com/b/BslL6i9p/mana-biblibre
>> > > trello not public, claire, the owner is not here today, we'll change
>> the
>> > > status in a day or 2.) Note that there can be some French on trello,
>> even
>> > > if Morgane avoid it.
>> > > We plan to have MANA working at the end of august, at least for
>> > > subscriptions (pattern & numbering) sharing. Maybe also for SQL
>> reports &
>> > > vendors.
>> > >
>> > > Some screen shots & features descriptions:
>> > >
>> > >  in subscription management, you can now *share* a subscription
>> pattern,
>> > > by sending it to Mana:
>> > >
>> > > When you click on "share", after validation, you get a *feedback*:
>> > >
>> > >
>> > >
>> > > Anyone can then retrieve the numbering pattern & frequency calculation
>> > > when creating a subscription (work being done this week). After the
>> 1st
>> > > screen of subscription creation, Koha will automatically query mana
>> and
>> > > check if there is some data available:
>> > >
>> > >
>> > > The librarian will then be able to see what is available and get it
>> > > locally in one click.
>> > > Every time a librarian "get it locally", a counter will be
>> incremented on
>> > > Mana. Thus, if more than 1 frequency/pattern is submitted for a given
>> > > title, the librarians should be able to see which one is "preferred"
>> by
>> > > other librarians.
>> > >
>> > > Additional features:
>> > >  * we will create a script that will help populate Mana from a CSV. We
>> > > will probably issue a RFF ("Request For File" ;-) ) later. Our idea is
>> > that
>> > > we want to launch Mana with many data already available.
>> > >  * comment. Any librarian will be able to add a comment to a shared
>> data,
>> > > as well as marking it as "obsolete".
>> > >  * a syspref will be added to deactivate Mana (will be ON by default)
>> > >
>> > > Feel free to ask for more informations, I would be happy to answer !
>> > >
>> > > --
>> > > Paul Poulain, Associ?-g?rant / co-owner
>> > > BibLibre, Services en logiciels libres pour les biblioth?ques
>> > > BibLibre, Open Source software and services for libraries
>> > >
>> > > _______________________________________________
>> > > Koha mailing list  http://koha-community.org
>> > > Koha at lists.katipo.co.nz
>> > > https://lists.katipo.co.nz/mailman/listinfo/koha
>> > >
>> > _______________________________________________
>> > Koha mailing list  http://koha-community.org
>> > Koha at lists.katipo.co.nz
>> > https://lists.katipo.co.nz/mailman/listinfo/koha
>> >
>> _______________________________________________
>> Koha mailing list  http://koha-community.org
>> Koha at lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>
>
>
>
> --
>
> *Hugo Agud - Orex Digital *
>
> *www.orex.es <http://www.orex.es>*
>
>
> <http://www.orex.es/>  [image: http://orex.es] <http://orex.es>
> <http://www.orex.es>
>
>
> Director
>
> Passatge de la Llan?adera, 3 ? 08338 Premi? de Dalt - Tel: 93 539 40 70
> 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.
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/5ec4d7dc/attachment-0001.html>

From sophie.meynieux at biblibre.com  Wed Jul 13 16:58:40 2016
From: sophie.meynieux at biblibre.com (Sophie Meynieux)
Date: Wed, 13 Jul 2016 16:58:40 +0200
Subject: [Koha-devel] mailing list creation for greek koha community
In-Reply-To: <CAAMU9tcD-oYky4aXKZP=1cyw8qdq0OyTujHLTGLV5zbLNSQiMw@mail.gmail.com>
References: <CAAMU9tcD-oYky4aXKZP=1cyw8qdq0OyTujHLTGLV5zbLNSQiMw@mail.gmail.com>
Message-ID: <57865720.7020400@biblibre.com>

Hi Giannis,

Laurent who manages the mailing list have created the greek one, on June 
30th. You should have received the pass sent directly by mailman. If not 
the case, tell me

S. Meynieux

-- 
Responsable support
BibLibre
+ 33 (0)4 91 81 35 08
http://www.biblibre.com

Le 13/07/2016 08:37, ??????? ?????????? a ?crit :
> dear developers list
>
> a month ago, I sent the following mail to 
> mailman at lists.koha-community.org 
> <mailto:mailman at lists.koha-community.org>.
>
> -----
> -Dear administrators
> -
> -as we are trying to establish the Greek Koha Users Group, we would 
> also like to create the Greek koha users mailing list. I understand 
> that we -need a "List creator's (authentication) password". Could you 
> provide it?
> -
> -thank you
> ?-----
>
> ?I have not received any response since. ?If any administrator of the 
> koha mailing lists sees this, please respond...
>
> thank you
>
> -------------------------------------------------------------
> ??????? ??????????
> ?????????? ??? ?????? ???????????? ?.?.?.
> ????? ???????? ???????????
> ???: 2310995368
> Fax: 2310995364
>
> -|Giannis Kourmoulis
> -|Library and Information Centre A.U.Th <http://A.U.Th>.
> -|Technical Support Team
> -|Tel: +302310995368
> -|Fax: +302310995364
>
> email:libsupport at lib.auth.gr <mailto:email%3Alibsupport at lib.auth.gr>
> -------------------------------------------------------------
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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/

-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/0bb68f48/attachment.html>

From kohanews at gmail.com  Thu Jul 14 02:28:58 2016
From: kohanews at gmail.com (kohanews)
Date: Wed, 13 Jul 2016 17:28:58 -0700
Subject: [Koha-devel] Call for News: July 2016 Newsletter
Message-ID: <5786DCCA.2090300@gmail.com>

Fellow Koha users ~

I'm collecting news for the July 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.

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160713/d84f61aa/attachment.html>

From mtompset at hotmail.com  Fri Jul 15 04:15:19 2016
From: mtompset at hotmail.com (Mark Tompsett)
Date: Fri, 15 Jul 2016 02:15:19 +0000
Subject: [Koha-devel] Easy sign offs...
Message-ID: <BY2PR0401MB175294981112A7CE30ABED48C6330@BY2PR0401MB1752.namprd04.prod.outlook.com>

Greetings,

I?m focusing on the tests right now, as I want to rip out some functionality in order to refactor (turn OpacHiddenItems into a filter rather than a series of messy subroutines all over the place), and only get warnings/errors related to my destruction. To this end, I have some easy sign offs awaiting people?s perusal:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16809
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16864
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16868

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10148
-- I?m positive Nicole said she couldn?t reproduce 006 either somewhere, but I can?t find it.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16856

GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160715/1e53667a/attachment.html>

From ISM at kis.in  Mon Jul 18 05:14:07 2016
From: ISM at kis.in (KIS ISM)
Date: Mon, 18 Jul 2016 03:14:07 +0000
Subject: [Koha-devel] Merge two Koha patron accounts
Message-ID: <1a5314cbb9154b7fab1408b573898902@SerEx1.kis.in>

Dear Koha specialists,

We have - by accident - created the new student accounts with the barcode extension -16 for the current year.

Is there a SQL script that would allow me to merge two patron accounts (like xxxxx and xxxxx-16 into one account as xxxxx-16)?
We are running Koha 3.16.03

Students have already checked out books on the new accounts so I can't just delete them.

Thank you for your help with this.

Rudy Wuthrich
Kodaikanal International School
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160718/15ae5fbf/attachment.html>

From rania.azad at auis.edu.krd  Wed Jul 20 07:45:45 2016
From: rania.azad at auis.edu.krd (rania azad mohammed)
Date: Wed, 20 Jul 2016 08:45:45 +0300
Subject: [Koha-devel] log file of activities for admin of koha in the library
Message-ID: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>

Dear

We are 3 admins in the library working on shifts in the library, each of us
log-in during her time. I want a report or log file to see all the
activities of each admin during a specific day. is there such report or
file? I tried to find it using the wiki but hopeless

-- 

*Regards,*


*Rania Azad |* Library Manager
Library Department
http://library.auis.edu.iq/
The American University of Iraq, Sulaimani
Office:
*B-G-32* Ext *1219*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160720/d71626d0/attachment.html>

From michael.hafen at washk12.org  Wed Jul 20 18:48:13 2016
From: michael.hafen at washk12.org (Michael Hafen)
Date: Wed, 20 Jul 2016 10:48:13 -0600
Subject: [Koha-devel] log file of activities for admin of koha in the
	library
In-Reply-To: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
Message-ID: <CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>

The action_logs table in the database could hold that information if you
have turned on logging in the system preferences (
http://translate.koha-community.org/manual/3.22/en/html-desktop/#logs).
There is a Log Viewer in Tools that may be useful for getting information
from this table, or you can try building an SQL Report by hand.

On Tue, Jul 19, 2016 at 11:45 PM, rania azad mohammed <
rania.azad at auis.edu.krd> wrote:

> Dear
>
> We are 3 admins in the library working on shifts in the library, each of
> us log-in during her time. I want a report or log file to see all the
> activities of each admin during a specific day. is there such report or
> file? I tried to find it using the wiki but hopeless
>
> --
>
> *Regards,*
>
>
> *Rania Azad |* Library Manager
> Library Department
> http://library.auis.edu.iq/
> The American University of Iraq, Sulaimani
> Office:
> *B-G-32* Ext *1219*
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160720/45e7f1f6/attachment.html>

From jonathan.druart at bugs.koha-community.org  Thu Jul 21 12:27:28 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Thu, 21 Jul 2016 11:27:28 +0100
Subject: [Koha-devel] Benchmarks for QA tools
Message-ID: <CAJzKNY4TT2nYt2D+Oyhpr_p_hi58Y2teZ5whHrErm+R1+B2Skw@mail.gmail.com>

Hi devs,

During the last dev meeting [1] we discussed about the ability to add
some benchmarks to the QA tools.
I have written a prove of concept and push it to a branch [2].
I'd like to get feedbacks as I don't like how it works actually:
1/ It adds calls to C4 and Koha methods from the QA tools, while until
now the QA tools where kind of independent of the Koha API
2/ The results are not really convincing: the time diff strongly
changes from one execution to the others. I can get +15% and then -15%
with the same patchset.

Any ideas how we could improve them?

Cheers,
Jonathan


[1] http://meetings.koha-community.org/2016/development_irc_meeting_13_july_2016.2016-07-13-14.08.txt
[2] https://github.com/joubu/koha-qa-test/tree/benchmarks

From jonathan.druart at bugs.koha-community.org  Thu Jul 21 13:20:13 2016
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Thu, 21 Jul 2016 12:20:13 +0100
Subject: [Koha-devel] Koha namespace architecture - calls for discussions
Message-ID: <CAJzKNY5xN0yihnhBSvC1FVzOajahgNfcr8qmCCWkUV_LyZRi1Q@mail.gmail.com>

Hi devs (me again),

During the last dev meeting, we discussed about the naming of a new
module in our Koha namespace. The conclusion was to ask the ML in
order to get more ideas (as there was not a lot of attendees...).
I'd like to take this opportunity to bring other architecture problems
I faced recently (Bug 16846 - Move patron related code to
Koha::Patron).

1/ Import stuffs modules
The initial discussion comes from 2 modules which have been added in 2
different bug reports about the same thought [1].
To provide a module to import patron, the author of bug 12598 chose
Koha::Patrons::Import when I chose Koha::Exporter::Record on bug 14722
(the first one is about importing patrons, the second one is about
exporting records (biblios, authorities)).
We need to uniformise these 2 namespaces to keep consistency.
The different possibilities are:
  a. Koha::Patrons::Import
  b. Koha::Importer::Patrons
  c. Koha::Importer::Patron
  d. Koha::Import::Patrons
  e. Koha::Import::Patron

My opinion is that having Koha::Exporter|Importer::Objects will add
the ability to have a Koha::Exporter|Importer module to group
export/import methods, if we want to (Objects means Patrons, Records,
Lists(Shelves), Reports, etc.)
But we could imagine a generic Koha::Exporter|Importer modules with
specific Koha::Object[s?]::Export|Import modules.

2/ Move C4::Members::GetBorrowersWithIssuesHistoryOlderThan to the
Koha namespace
This subroutine is supposed to return the patrons with an issue
history older than a given date.
I first chose to move this code to
Koha::Patrons->search_with_issues_history_older_than
But looking at the code you will find that the subroutine actually
returns the borrowernumber with the number of old issues (matching the
"older than" date).
IMO it would make sense to return the patrons (Koha::Patron) instead
of just the borrowernumber, but we will have to join the 2 tables,
which can lead to a perf issue (ref needed). This idea is enforced by
the fact that GetBorrowersWhoHaveNeverBorrowed and
GetBorrowersToExpunge fit perfectly into Koha::Patrons.
Otherwise we could decide to move the subroutine to a method of
Koha::OldIssues, to avoid the join. But that sounds weird to me.

3/ Move C4::Ratings
I have started to move C4::Ratings to Koha::Rating[s]
Everything went fine until I decided to move C4::Rating::GetRating. It
actually calculates the ratings avg for a record and returns a hashref
with different values, and not a Koha::Rating object.
I think we need to split up with
  Koha::Ratings->search({ biblionumber => $biblionumber
})->calculate_avg (or something similar)
and
  Koha::Ratings->search({ biblionumber => $biblionumber,
borrowernumber => $borrowernumber }); # which will return a
Koha::Rating object
In that case, 1 call to C4::Ratings::GetRating will be replaced with 2 calls.
Does that make sense?

4/ Move subroutines not directly related to a Koha::Object
In some cases, the move is not very obvious. For instance we have
C4::Members::checkcardnumber and C4::Members::get_cardnumber_length,
they are strongly linked and I think we would like to keep them
together.
We could imagine a Koha::Patron::Cardnumber to move
get_cardnumber_length in, but it does not represent a patron's
cardnumber, so it could be confusing.
checkcardnumber could go easily to Koha::Patron->check_new_cardnumber(
$new_cardnumber )

5/ patronflags?
Any ideas what we could do with C4::Members::patronflags? :)

Others will certainly come later!

Cheers,
Jonathan

[1] http://meetings.koha-community.org/2016/development_irc_meeting_13_july_2016.2016-07-13-14.08.log.html
from 14:29:48 <cait> #info Topic: Koha::Patrons::Import (bug 12598) vs
Koha::Exporter::Record (bug 14722)

From M.de.Rooy at rijksmuseum.nl  Thu Jul 21 13:54:18 2016
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 21 Jul 2016 11:54:18 +0000
Subject: [Koha-devel] Koha namespace architecture - calls for discussions
In-Reply-To: <CAJzKNY5xN0yihnhBSvC1FVzOajahgNfcr8qmCCWkUV_LyZRi1Q@mail.gmail.com>
References: <CAJzKNY5xN0yihnhBSvC1FVzOajahgNfcr8qmCCWkUV_LyZRi1Q@mail.gmail.com>
Message-ID: <VI1PR0501MB25916E2AE20F0B0ABB75732DCE090@VI1PR0501MB2591.eurprd05.prod.outlook.com>

> 1/ Import stuffs modules
> But we could imagine a generic Koha::Exporter|Importer modules with specific Koha::Object[s?]::Export|Import modules.
Sounds good to me: If Patron export needs some additional functionality, add Koha::Patron::Export on top of Koha::Exporter.

> 2/ Move C4::Members::GetBorrowersWithIssuesHistoryOlderThan to the Koha namespace This subroutine is supposed to return the patrons 
> with an issue history older than a given date.
> Otherwise we could decide to move the subroutine to a method of Koha::OldIssues, to avoid the join. But that sounds weird to me.
Agreed. Not very intuitive to put a GetBorrowers... inside OldIssues.

> 3/ Move C4::Ratings
May not understand it fully. But calculate_avg can return the hashref with values ?

> 4/ Move subroutines not directly related to a Koha::Object In some cases, the move is not very obvious. For instance we have 
> C4::Members::checkcardnumber and C4::Members::get_cardnumber_length,
If get_cardnumber_length in Members is not about a patron's cardnumber, maybe we should not keep them together. 

> 5/ patronflags?
Separate object ?


From tomascohen at gmail.com  Thu Jul 21 14:41:07 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 21 Jul 2016 12:41:07 +0000
Subject: [Koha-devel] Koha namespace architecture - calls for discussions
In-Reply-To: <CAJzKNY5xN0yihnhBSvC1FVzOajahgNfcr8qmCCWkUV_LyZRi1Q@mail.gmail.com>
References: <CAJzKNY5xN0yihnhBSvC1FVzOajahgNfcr8qmCCWkUV_LyZRi1Q@mail.gmail.com>
Message-ID: <CABZfb=UhwZ1PMqrjOfZxr9A+cMGLFTXYiHKErt_eP6ofs5n3eQ@mail.gmail.com>

El jue., 21 jul. 2016 a las 8:20, Jonathan Druart (<
jonathan.druart at bugs.koha-community.org>) escribi?:

> Hi devs (me again),
>
> During the last dev meeting, we discussed about the naming of a new
> module in our Koha namespace. The conclusion was to ask the ML in
> order to get more ideas (as there was not a lot of attendees...).
> I'd like to take this opportunity to bring other architecture problems
> I faced recently (Bug 16846 - Move patron related code to
> Koha::Patron).
>
> 1/ Import stuffs modules
> The initial discussion comes from 2 modules which have been added in 2
> different bug reports about the same thought [1].
> To provide a module to import patron, the author of bug 12598 chose
> Koha::Patrons::Import when I chose Koha::Exporter::Record on bug 14722
> (the first one is about importing patrons, the second one is about
> exporting records (biblios, authorities)).
> We need to uniformise these 2 namespaces to keep consistency.
> The different possibilities are:
>   a. Koha::Patrons::Import
>   b. Koha::Importer::Patrons
>   c. Koha::Importer::Patron
>   d. Koha::Import::Patrons
>   e. Koha::Import::Patron
>
> My opinion is that having Koha::Exporter|Importer::Objects will add
> the ability to have a Koha::Exporter|Importer module to group
> export/import methods, if we want to (Objects means Patrons, Records,
> Lists(Shelves), Reports, etc.)
> But we could imagine a generic Koha::Exporter|Importer modules with
> specific Koha::Object[s?]::Export|Import modules.
>

+1 For having a general Import/Export class to subclass for different
Koha::Object types.


> 2/ Move C4::Members::GetBorrowersWithIssuesHistoryOlderThan to the
> Koha namespace
> This subroutine is supposed to return the patrons with an issue
> history older than a given date.
> I first chose to move this code to
> Koha::Patrons->search_with_issues_history_older_than
> But looking at the code you will find that the subroutine actually
> returns the borrowernumber with the number of old issues (matching the
> "older than" date).
> IMO it would make sense to return the patrons (Koha::Patron) instead
> of just the borrowernumber, but we will have to join the 2 tables,
> which can lead to a perf issue (ref needed). This idea is enforced by
> the fact that GetBorrowersWhoHaveNeverBorrowed and
> GetBorrowersToExpunge fit perfectly into Koha::Patrons.
> Otherwise we could decide to move the subroutine to a method of
> Koha::OldIssues, to avoid the join. But that sounds weird to me.
>

I'd move it to Koha::Patrons. The API change makes sense to me, but should
better look at the places it is used to know if it makes sense. (I'm sure
it does, because we are probably then using GetMember using those
borrowernumbers...)


> 3/ Move C4::Ratings
> I have started to move C4::Ratings to Koha::Rating[s]
> Everything went fine until I decided to move C4::Rating::GetRating. It
> actually calculates the ratings avg for a record and returns a hashref
> with different values, and not a Koha::Rating object.
> I think we need to split up with
>   Koha::Ratings->search({ biblionumber => $biblionumber
> })->calculate_avg (or something similar)
> and
>   Koha::Ratings->search({ biblionumber => $biblionumber,
> borrowernumber => $borrowernumber }); # which will return a
> Koha::Rating object
> In that case, 1 call to C4::Ratings::GetRating will be replaced with 2
> calls.
> Does that make sense?
>

I agree with this one too. It fits Koha::Ratings. I'm not sure why an
average calculation returns several values. It has to be tied to how it is
used on the UI.


> 4/ Move subroutines not directly related to a Koha::Object
> In some cases, the move is not very obvious. For instance we have
> C4::Members::checkcardnumber and C4::Members::get_cardnumber_length,
> they are strongly linked and I think we would like to keep them
> together.
> We could imagine a Koha::Patron::Cardnumber to move
> get_cardnumber_length in, but it does not represent a patron's
> cardnumber, so it could be confusing.
> checkcardnumber could go easily to Koha::Patron->check_new_cardnumber(
> $new_cardnumber )
>

Maybe time for 'Utils'? I always saw the Koha::Objects (plural) as a place
for utilitary stuff.


> 5/ patronflags?
> Any ideas what we could do with C4::Members::patronflags? :)
>

:-P


>
> Others will certainly come later!
>
> Cheers,
> Jonathan
>
> [1]
> http://meetings.koha-community.org/2016/development_irc_meeting_13_july_2016.2016-07-13-14.08.log.html
> from 14:29:48 <cait> #info Topic: Koha::Patrons::Import (bug 12598) vs
> Koha::Exporter::Record (bug 14722)
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/ce5eab7a/attachment-0001.html>

From lucianacoca1313 at gmail.com  Thu Jul 21 15:44:02 2016
From: lucianacoca1313 at gmail.com (Luciana Coca)
Date: Thu, 21 Jul 2016 10:44:02 -0300
Subject: [Koha-devel] 'Refine your search' is missing
In-Reply-To: <CAArtO+cwPE4y5e0yJ3SM-LedrR6GCu6Hu8V=E+j80J3fZMhcqg@mail.gmail.com>
References: <CAArtO+cwPE4y5e0yJ3SM-LedrR6GCu6Hu8V=E+j80J3fZMhcqg@mail.gmail.com>
Message-ID: <CAArtO+f4vyGd5q3tXSdvn7Z-xuRCesVhCJ4BSp=Zb6y86G_uAQ@mail.gmail.com>

I solved the problem. Thanks Tomas for your help!

I just changed the use_zebra_facets value in /etc/koha/koha-conf.xml

2016-07-18 12:13 GMT-03:00 Luciana Coca <lucianacoca1313 at gmail.com>:
> Hello everyone!
>
> I'm using Koha 3.22 on Debian 7.8.
>
> In Koha old versions there was an option 'Refine your search' that was
> very useful when we were searching on catalog. It appeared in the
> search results page.
>
> How can i get it back?
>
> Thank you for your help!
>
> Luciana.

From philippe.blouin at inlibro.com  Thu Jul 21 15:59:09 2016
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Thu, 21 Jul 2016 09:59:09 -0400
Subject: [Koha-devel] 16909 breaks member add
In-Reply-To: <CAArtO+f4vyGd5q3tXSdvn7Z-xuRCesVhCJ4BSp=Zb6y86G_uAQ@mail.gmail.com>
References: <CAArtO+cwPE4y5e0yJ3SM-LedrR6GCu6Hu8V=E+j80J3fZMhcqg@mail.gmail.com>
	<CAArtO+f4vyGd5q3tXSdvn7Z-xuRCesVhCJ4BSp=Zb6y86G_uAQ@mail.gmail.com>
Message-ID: <5790D52D.9050307@inlibro.com>

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16909

It's been pushed to master, but seemingly is the cause of not being able 
to add new member.  Pressing Save just brings us back to the page.

Not sure exactly what I should be doing with the status and importance 
of the bug, but this blocks further development (short term) and 
obviously any release (long term).
What is the correct procedure to raise the issue?

Thanks
Blou

Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/9bffe0be/attachment.html>

From veron at veron.ch  Thu Jul 21 17:15:04 2016
From: veron at veron.ch (=?UTF-8?Q?Marc_V=c3=a9ron?=)
Date: Thu, 21 Jul 2016 17:15:04 +0200
Subject: [Koha-devel] 16909 breaks member add
In-Reply-To: <5790D52D.9050307@inlibro.com>
References: <CAArtO+cwPE4y5e0yJ3SM-LedrR6GCu6Hu8V=E+j80J3fZMhcqg@mail.gmail.com>
	<CAArtO+f4vyGd5q3tXSdvn7Z-xuRCesVhCJ4BSp=Zb6y86G_uAQ@mail.gmail.com>
	<5790D52D.9050307@inlibro.com>
Message-ID: <4a5709a6-b44f-854d-de62-4f0afe721730@veron.ch>

Hi Blou,

See Bug 16941 - Can not add new patron in staff client

(Status Critical, PQA)

Marc


Am 21.07.2016 um 15:59 schrieb Philippe Blouin:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16909
>
> It's been pushed to master, but seemingly is the cause of not being 
> able to add new member.  Pressing Save just brings us back to the page.
>
> Not sure exactly what I should be doing with the status and importance 
> of the bug, but this blocks further development (short term) and 
> obviously any release (long term).
> What is the correct procedure to raise the issue?
>
> Thanks
> Blou
>
> Philippe Blouin,
> Responsable du d?veloppement informatique
>
> T?l.  : (888) 604-2627
> philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>
> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/b693cc12/attachment.html>

From philippe.blouin at inlibro.com  Thu Jul 21 17:19:48 2016
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Thu, 21 Jul 2016 11:19:48 -0400
Subject: [Koha-devel] 16909 breaks member add
In-Reply-To: <4a5709a6-b44f-854d-de62-4f0afe721730@veron.ch>
References: <CAArtO+cwPE4y5e0yJ3SM-LedrR6GCu6Hu8V=E+j80J3fZMhcqg@mail.gmail.com>
	<CAArtO+f4vyGd5q3tXSdvn7Z-xuRCesVhCJ4BSp=Zb6y86G_uAQ@mail.gmail.com>
	<5790D52D.9050307@inlibro.com>
	<4a5709a6-b44f-854d-de62-4f0afe721730@veron.ch>
Message-ID: <5790E814.9060604@inlibro.com>

Ha, very nice!  Already passed QA.

Thanks a lot, Marc!!

Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
On 07/21/2016 11:15 AM, Marc V?ron wrote:
>
> Hi Blou,
>
> See Bug 16941 - Can not add new patron in staff client
>
> (Status Critical, PQA)
>
> Marc
>
>
> Am 21.07.2016 um 15:59 schrieb Philippe Blouin:
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16909
>>
>> It's been pushed to master, but seemingly is the cause of not being 
>> able to add new member.  Pressing Save just brings us back to the page.
>>
>> Not sure exactly what I should be doing with the status and 
>> importance of the bug, but this blocks further development (short 
>> term) and obviously any release (long term).
>> What is the correct procedure to raise the issue?
>>
>> Thanks
>> Blou
>>
>> Philippe Blouin,
>> Responsable du d?veloppement informatique
>>
>> T?l.  : (888) 604-2627
>> philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>>
>> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/752260f6/attachment-0001.html>

From tomascohen at gmail.com  Thu Jul 21 17:55:46 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 21 Jul 2016 15:55:46 +0000
Subject: [Koha-devel] log file of activities for admin of koha in the
	library
In-Reply-To: <CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
Message-ID: <CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>

This patches will improve it and are worth testing do they get pushed :-)

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16829

El mi?., 20 jul. 2016 13:48, Michael Hafen <michael.hafen at washk12.org>
escribi?:

> The action_logs table in the database could hold that information if you
> have turned on logging in the system preferences (
> http://translate.koha-community.org/manual/3.22/en/html-desktop/#logs).
> There is a Log Viewer in Tools that may be useful for getting information
> from this table, or you can try building an SQL Report by hand.
>
> On Tue, Jul 19, 2016 at 11:45 PM, rania azad mohammed <
> rania.azad at auis.edu.krd> wrote:
>
>> Dear
>>
>> We are 3 admins in the library working on shifts in the library, each of
>> us log-in during her time. I want a report or log file to see all the
>> activities of each admin during a specific day. is there such report or
>> file? I tried to find it using the wiki but hopeless
>>
>> --
>>
>> *Regards,*
>>
>>
>> *Rania Azad |* Library Manager
>> Library Department
>> http://library.auis.edu.iq/
>> The American University of Iraq, Sulaimani
>> Office:
>> *B-G-32* Ext *1219*
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/e7e2c8aa/attachment.html>

From michael.hafen at washk12.org  Thu Jul 21 18:05:44 2016
From: michael.hafen at washk12.org (Michael Hafen)
Date: Thu, 21 Jul 2016 10:05:44 -0600
Subject: [Koha-devel] log file of activities for admin of koha in the
	library
In-Reply-To: <CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
Message-ID: <CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>

I don't think those patches will effect Rania's request for reports. Though
adding the interface column will be a nice feature.

On Jul 21, 2016 9:55 AM, "Tomas Cohen Arazi" <tomascohen at gmail.com> wrote:

> This patches will improve it and are worth testing do they get pushed :-)
>
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16829
>
> El mi?., 20 jul. 2016 13:48, Michael Hafen <michael.hafen at washk12.org>
> escribi?:
>
>> The action_logs table in the database could hold that information if you
>> have turned on logging in the system preferences (
>> http://translate.koha-community.org/manual/3.22/en/html-desktop/#logs).
>> There is a Log Viewer in Tools that may be useful for getting information
>> from this table, or you can try building an SQL Report by hand.
>>
>> On Tue, Jul 19, 2016 at 11:45 PM, rania azad mohammed <
>> rania.azad at auis.edu.krd> wrote:
>>
>>> Dear
>>>
>>> We are 3 admins in the library working on shifts in the library, each of
>>> us log-in during her time. I want a report or log file to see all the
>>> activities of each admin during a specific day. is there such report or
>>> file? I tried to find it using the wiki but hopeless
>>>
>>> --
>>>
>>> *Regards,*
>>>
>>>
>>> *Rania Azad |* Library Manager
>>> Library Department
>>> http://library.auis.edu.iq/
>>> The American University of Iraq, Sulaimani
>>> Office:
>>> *B-G-32* Ext *1219*
>>>
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> http://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
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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 (https://theke.io <http://theke.io/>)
> ? +54 9351 3513384
> GPG: B2F3C15F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/98ff8bab/attachment.html>

From philippe.blouin at inlibro.com  Thu Jul 21 18:43:34 2016
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Thu, 21 Jul 2016 12:43:34 -0400
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
Message-ID: <5790FBB6.8020009@inlibro.com>

Hi!

I'm throwing a line here, and I'd just like to get a feel for the value 
of offering some work to the community.  Mind you, the work is "big" so 
honest responses could save us lot of wasted hours.

We've developed a parallel calendar table to specify each individual day 
if it's opened or not (instead of rules and exception).  We added to it 
the opening hours, and keep a year of them in the past, and a year in 
the future.
The reasonning being:
- We need the opening hours.  They need to vary season to seasons. We 
need them for hourly and minute loans.
- Exception and holidays and etc... are complicated.  To manage, to 
calculate, to fix.  We need the past info as well, to calculate precisely.
- Performance.  Calculating with C4/Koha Calendars is sloooooooooow.  
Our little table cut fines.pl calculation times by 97%.  Not a typo.  
Checkout improvement by 30-60% but metric is unreliable so take with 
grain of salt this one.

So before I go and write a wiki RFC, then open bugzillas, make the code 
community acceptable (we're not using Schemas), complete it, write 
tests, etc...  Is there an interest?  Would it answer a need (outside of 
our clients) ?  Maybe a subset?

All comments, suggestions, questions are welcomed.

High regards,

Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/b325a4ca/attachment-0001.html>

From michael.hafen at washk12.org  Thu Jul 21 19:03:30 2016
From: michael.hafen at washk12.org (Michael Hafen)
Date: Thu, 21 Jul 2016 11:03:30 -0600
Subject: [Koha-devel] log file of activities for admin of koha in the
	library
In-Reply-To: <CAPK2MLsEMJ+w519x+Gczv4_KdHKs2+pQos8HkY5pEUQCEdTNZg@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CAPK2MLsEMJ+w519x+Gczv4_KdHKs2+pQos8HkY5pEUQCEdTNZg@mail.gmail.com>
Message-ID: <CAAh7UdnejmpypbURxCKN2wyUrGCT7eVWrfJxseNTUP-ChKRF_w@mail.gmail.com>

Ok, for the Guided Reports the SQL will be something like:

SELECT al.timestamp AS DateAndTime,b.surname,b.firstname,module,action FROM
action_logs AS al LEFT JOIN borrowers AS b ON user = b.borrowernumber WHERE
user <> 0 AND al.timestamp BETWEEN <<Between (yyyy-mmd-dd)|date>> AND <<And
(yyyy-nn-dd)|date>> ORDER BY b.surname,b.firstname,al.timestamp

You may want to adjust the order by with asc or desc qualifiers on the
timestamp.

But this only works for periods where you have the logging enabled, and
only for those modules that are enabled.  For example I don't see
circulation when I run that SQL because I don't have logging enabled for
that module.

On Thu, Jul 21, 2016 at 4:46 AM, rania azad mohammed <
rania.azad at auis.edu.krd> wrote:

> Oh I see,
> Can you help me on building the SQL query since I don't have a lot of
> knowledge with SQL? simple report on librarian activities circulation,items
> and cataloguing with date and time will be perfect
>
>
>
> On Wed, Jul 20, 2016 at 7:48 PM, Michael Hafen <michael.hafen at washk12.org>
> wrote:
>
>> The action_logs table in the database could hold that information if you
>> have turned on logging in the system preferences (
>> http://translate.koha-community.org/manual/3.22/en/html-desktop/#logs).
>> There is a Log Viewer in Tools that may be useful for getting information
>> from this table, or you can try building an SQL Report by hand.
>>
>> On Tue, Jul 19, 2016 at 11:45 PM, rania azad mohammed <
>> rania.azad at auis.edu.krd> wrote:
>>
>>> Dear
>>>
>>> We are 3 admins in the library working on shifts in the library, each of
>>> us log-in during her time. I want a report or log file to see all the
>>> activities of each admin during a specific day. is there such report or
>>> file? I tried to find it using the wiki but hopeless
>>>
>>> --
>>>
>>> *Regards,*
>>>
>>>
>>> *Rania Azad |* Library Manager
>>> Library Department
>>> http://library.auis.edu.iq/
>>> The American University of Iraq, Sulaimani
>>> Office:
>>> *B-G-32* Ext *1219*
>>>
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> http://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
>>
>>
>
>
> --
>
> *Regards,*
>
>
> *Rania Azad |* Library Manager
> Library Department
> http://library.auis.edu.iq/
> The American University of Iraq, Sulaimani
> Office:
> *B-G-32* Ext *1219*
>
>
>


-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/f9b0233b/attachment.html>

From tomascohen at gmail.com  Thu Jul 21 20:23:33 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 21 Jul 2016 18:23:33 +0000
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <5790FBB6.8020009@inlibro.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
	<5790FBB6.8020009@inlibro.com>
Message-ID: <CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com>

I'm all for speed improvements. But:
- A clear backwards-compatible upgrade path needs to be set and written.
- I think (because of the speed improvement) that you are realying more on
the DB features, this needs to be discussed if it can cause trouble.
- The less you change the API, the easier is to spot regressions for the
current blacklist-like implementation of the calendar. Tests could be
adjusted, but it'd be interesting to have the current tests pass.


Regards

El jue., 21 jul. 2016 a las 13:43, Philippe Blouin (<
philippe.blouin at inlibro.com>) escribi?:

> Hi!
>
> I'm throwing a line here, and I'd just like to get a feel for the value of
> offering some work to the community.  Mind you, the work is "big" so honest
> responses could save us lot of wasted hours.
>
> We've developed a parallel calendar table to specify each individual day
> if it's opened or not (instead of rules and exception).  We added to it the
> opening hours, and keep a year of them in the past, and a year in the
> future.
> The reasonning being:
> - We need the opening hours.  They need to vary season to seasons.  We
> need them for hourly and minute loans.
> - Exception and holidays and etc... are complicated.  To manage, to
> calculate, to fix.  We need the past info as well, to calculate precisely.
> - Performance.  Calculating with C4/Koha Calendars is sloooooooooow.  Our
> little table cut fines.pl calculation times by 97%.  Not a typo.
> Checkout improvement by 30-60% but metric is unreliable so take with grain
> of salt this one.
>
> So before I go and write a wiki RFC, then open bugzillas, make the code
> community acceptable (we're not using Schemas), complete it, write tests,
> etc...  Is there an interest?  Would it answer a need (outside of our
> clients) ?  Maybe a subset?
>
> All comments, suggestions, questions are welcomed.
>
> High regards,
>
> Philippe Blouin,
> Responsable du d?veloppement informatique
>
> T?l.  : (888) 604-2627
> philippe.blouin at inLibro.com
> inLibro | pour esprit libre | www.inLibro.com
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/852d0d85/attachment.html>

From rania.azad at auis.edu.krd  Thu Jul 21 20:47:22 2016
From: rania.azad at auis.edu.krd (rania azad mohammed)
Date: Thu, 21 Jul 2016 21:47:22 +0300
Subject: [Koha-devel] log file of activities for admin of koha in the
	library
In-Reply-To: <CAAh7UdnejmpypbURxCKN2wyUrGCT7eVWrfJxseNTUP-ChKRF_w@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CAPK2MLsEMJ+w519x+Gczv4_KdHKs2+pQos8HkY5pEUQCEdTNZg@mail.gmail.com>
	<CAAh7UdnejmpypbURxCKN2wyUrGCT7eVWrfJxseNTUP-ChKRF_w@mail.gmail.com>
Message-ID: <CAPK2MLvdRxZa-2-TzDrfE-758GRj2P-vgyXJ9UknLuos9HKcHg@mail.gmail.com>

Oh that's great, I will do the necessary modification then I will posted
back for the benifit of everyone, or you can added in the sql report
Will be back to you soon
Thanks again

On Thursday, 21 July 2016, Michael Hafen <michael.hafen at washk12.org> wrote:

> Ok, for the Guided Reports the SQL will be something like:
>
> SELECT al.timestamp AS DateAndTime,b.surname,b.firstname,module,action
> FROM action_logs AS al LEFT JOIN borrowers AS b ON user = b.borrowernumber
> WHERE user <> 0 AND al.timestamp BETWEEN <<Between (yyyy-mmd-dd)|date>>
> AND <<And (yyyy-nn-dd)|date>> ORDER BY b.surname,b.firstname,al.timestamp
>
> You may want to adjust the order by with asc or desc qualifiers on the
> timestamp.
>
> But this only works for periods where you have the logging enabled, and
> only for those modules that are enabled.  For example I don't see
> circulation when I run that SQL because I don't have logging enabled for
> that module.
>
> On Thu, Jul 21, 2016 at 4:46 AM, rania azad mohammed <
> rania.azad at auis.edu.krd
> <javascript:_e(%7B%7D,'cvml','rania.azad at auis.edu.krd');>> wrote:
>
>> Oh I see,
>> Can you help me on building the SQL query since I don't have a lot of
>> knowledge with SQL? simple report on librarian activities circulation,items
>> and cataloguing with date and time will be perfect
>>
>>
>>
>> On Wed, Jul 20, 2016 at 7:48 PM, Michael Hafen <michael.hafen at washk12.org
>> <javascript:_e(%7B%7D,'cvml','michael.hafen at washk12.org');>> wrote:
>>
>>> The action_logs table in the database could hold that information if you
>>> have turned on logging in the system preferences (
>>> http://translate.koha-community.org/manual/3.22/en/html-desktop/#logs).
>>> There is a Log Viewer in Tools that may be useful for getting information
>>> from this table, or you can try building an SQL Report by hand.
>>>
>>> On Tue, Jul 19, 2016 at 11:45 PM, rania azad mohammed <
>>> rania.azad at auis.edu.krd
>>> <javascript:_e(%7B%7D,'cvml','rania.azad at auis.edu.krd');>> wrote:
>>>
>>>> Dear
>>>>
>>>> We are 3 admins in the library working on shifts in the library, each
>>>> of us log-in during her time. I want a report or log file to see all the
>>>> activities of each admin during a specific day. is there such report or
>>>> file? I tried to find it using the wiki but hopeless
>>>>
>>>> --
>>>>
>>>> *Regards,*
>>>>
>>>>
>>>> *Rania Azad |* Library Manager
>>>> Library Department
>>>> http://library.auis.edu.iq/
>>>> The American University of Iraq, Sulaimani
>>>> Office:
>>>> *B-G-32* Ext *1219*
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Koha-devel mailing list
>>>> Koha-devel at lists.koha-community.org
>>>> <javascript:_e(%7B%7D,'cvml','Koha-devel at lists.koha-community.org');>
>>>> http://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
>>>
>>>
>>
>>
>> --
>>
>> *Regards,*
>>
>>
>> *Rania Azad |* Library Manager
>> Library Department
>> http://library.auis.edu.iq/
>> The American University of Iraq, Sulaimani
>> Office:
>> *B-G-32* Ext *1219*
>>
>>
>>
>
>
> --
> Michael Hafen
> Washington County School District Technology Department
> Systems Analyst
>
>

-- 

*Regards,*


*Rania Azad |* Library Manager
Library Department
http://library.auis.edu.iq/
The American University of Iraq, Sulaimani
Office:
*B-G-32* Ext *1219*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/3035f5f5/attachment-0001.html>

From philippe.blouin at inlibro.com  Thu Jul 21 21:30:28 2016
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Thu, 21 Jul 2016 15:30:28 -0400
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
	<5790FBB6.8020009@inlibro.com>
	<CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com>
Message-ID: <579122D4.3090407@inlibro.com>

On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:
> I'm all for speed improvements. But:
> - A clear backwards-compatible upgrade path needs to be set and written.
Our curent script takes the content of the "old" tables to create the 
new one.  Past and future.  Is that what you mean?
More so, I've split the work in 8 theoretical steps.  But I think it 
could be considered to offer both ways in parallel: just add the new DB 
table, slowly transfer the calls to the new library.  Just make sure the 
new table is populated on any call to modify the "old ones".
> - I think (because of the speed improvement) that you are realying 
> more on the DB features, this needs to be discussed if it can cause 
> trouble.
Actually, that's the serious point: we're going simple SELECTs the old 
way.  With no cache or anything right now.  It's not the fact that the 
code is cut by 80% or anything (although it would be). It's just that 
much faster to do date calculations using the DB than Perl's DateTime.  
Something like...

SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?) AND 
(isopen=1)

Add in opening and closing hours and it's golden.  Easily hashable and 
cachable as well.

> - The less you change the API, the easier is to spot regressions for 
> the current blacklist-like implementation of the calendar. Tests could 
> be adjusted, but it'd be interesting to have the current tests pass.
I agree.  I admit I do not have a clear plan, and I know without perfect 
test coverage, this stands no chance.  More so, wasting perfectly valid 
old tests is... a waste.

But again, I'm throwing a line.  I want to see if others beside us see a 
need.  I want to see if someone is already working on something that 
would conflict, etc...
>
> Regards
Thanks a lot for the feedback!

>
> El jue., 21 jul. 2016 a las 13:43, Philippe Blouin 
> (<philippe.blouin at inlibro.com <mailto:philippe.blouin at inlibro.com>>) 
> escribi?:
>
>     Hi!
>
>     I'm throwing a line here, and I'd just like to get a feel for the
>     value of offering some work to the community.  Mind you, the work
>     is "big" so honest responses could save us lot of wasted hours.
>
>     We've developed a parallel calendar table to specify each
>     individual day if it's opened or not (instead of rules and
>     exception).  We added to it the opening hours, and keep a year of
>     them in the past, and a year in the future.
>     The reasonning being:
>     - We need the opening hours.  They need to vary season to
>     seasons.  We need them for hourly and minute loans.
>     - Exception and holidays and etc... are complicated.  To manage,
>     to calculate, to fix.  We need the past info as well, to calculate
>     precisely.
>     - Performance.  Calculating with C4/Koha Calendars is
>     sloooooooooow.  Our little table cut fines.pl <http://fines.pl>
>     calculation times by 97%. Not a typo.  Checkout improvement by
>     30-60% but metric is unreliable so take with grain of salt this one.
>
>     So before I go and write a wiki RFC, then open bugzillas, make the
>     code community acceptable (we're not using Schemas), complete it,
>     write tests, etc...  Is there an interest?  Would it answer a need
>     (outside of our clients) ?  Maybe a subset?
>
>     All comments, suggestions, questions are welcomed.
>
>     High regards,
>
>     Philippe Blouin,
>     Responsable du d?veloppement informatique
>
>     T?l.  : (888) 604-2627
>     philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>
>     inLibro | pour esprit libre | www.inLibro.com
>     <http://www.inLibro.com>
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at lists.koha-community.org>
>     http://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 (https://theke.io <http://theke.io/>)
> ? +54 9351 3513384
> GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/44e64af8/attachment.html>

From paul.a at navalmarinearchive.com  Fri Jul 22 00:01:02 2016
From: paul.a at navalmarinearchive.com (Paul A)
Date: Thu, 21 Jul 2016 18:01:02 -0400
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <579122D4.3090407@inlibro.com>
References: <CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com>
	<CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
	<5790FBB6.8020009@inlibro.com>
	<CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com>
Message-ID: <5.2.1.1.2.20160721164410.036a9908@pop.navalmarinearchive.com>

At 03:30 PM 7/21/2016 -0400, Philippe Blouin wrote:
>On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:
>>I'm all for speed improvements. But:
[snip]
>>- I think (because of the speed improvement) that you are realying more 
>>on the DB features, this needs to be discussed if it can cause trouble.
>Actually, that's the serious point: we're going simple SELECTs the old 
>way.?  With no cache or anything right now.?  It's not the fact that the 
>code is cut by 80% or anything (although it would be).?  It's just that 
>much faster to do date calculations using the DB than Perl's DateTime.?

Just some thoughts, because I do not know where Koha is with MySQL 5.7 
which is appreciably faster than 5.5/5.6 (we have, without trouble, got 
Koha 3.08 up and running -- but have had no luck updating to the 16.05 db 
structure on 5.7 and I haven't had time to look into the deltas.) Oracle 
claims a 3x improvement in read-only speed, our testing confirms it...

However, +1 for Philippe's train of thought. I have always favoured direct 
interrogation of the db rather than bifurcating through various libraries 
unless the "value added" is incontrovertible. But backwards compatibility 
(or at least flaw-free updating scripts) for an open-source project as 
important as Koha must be considered.

As to calendars, these are a pet peeve with my employees and volunteers -- 
we have them all over the place, google maps, facebook, yellow pages, our 
own website, numerous community links (probably more that I can't remember, 
or are "copied" by other services e.g. bing maps appears to copy google 
maps) so we would not be looking for yet another one to manage. But if 
that's what the Koha community wants, there's no objections from me :=}

Best -- Paul

>Something like...
>
>SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?) AND 
>(isopen=1)
>
>Add in opening and closing hours and it's golden.?  Easily hashable and 
>cachable as well.
>
>>- The less you change the API, the easier is to spot regressions for the 
>>current blacklist-like implementation of the calendar. Tests could be 
>>adjusted, but it'd be interesting to have the current tests pass.
>I agree.?  I admit I do not have a clear plan, and I know without perfect 
>test coverage, this stands no chance.?  More so, wasting perfectly valid 
>old tests is... a waste.
>
>But again, I'm throwing a line.?  I want to see if others beside us see a 
>need.?  I want to see if someone is already working on something that 
>would conflict, etc...
>>
>>Regards
>Thanks a lot for the feedback!
>
>>
>>El jue., 21 jul. 2016 a las 13:43, Philippe Blouin 
>>(<philippe.blouin at inlibro.com>) escribi??:
>>Hi!
>>
>>I'm throwing a line here, and I'd just like to get a feel for the value 
>>of offering some work to the community.?  Mind you, the work is "big" so 
>>honest responses could save us lot of wasted hours.
>>
>>We've developed a parallel calendar table to specify each individual day 
>>if it's opened or not (instead of rules and exception).?  We added to it 
>>the opening hours, and keep a year of them in the past, and a year in the 
>>future.
>>The reasonning being:
>>- We need the opening hours.?  They need to vary season to seasons.?  We 
>>need them for hourly and minute loans.
>>- Exception and holidays and etc... are complicated.?  To manage, to 
>>calculate, to fix.?  We need the past info as well, to calculate precisely.
>>- Performance.?  Calculating with C4/Koha Calendars is 
>>sloooooooooow.?  Our little table cut fines.pl calculation times by 
>>97%.?  Not a typo.?  Checkout improvement by 30-60% but metric is 
>>unreliable so take with grain of salt this one.
>>
>>So before I go and write a wiki RFC, then open bugzillas, make the code 
>>community acceptable (we're not using Schemas), complete it, write tests, 
>>etc...?  Is there an interest??  Would it answer a need (outside of our 
>>clients) ??  Maybe a subset??
>>
>>All comments, suggestions, questions are welcomed.
>>
>>High regards,
>>
>>Philippe Blouin,
>>Responsable du d??veloppement informatique


From pianohacker at gmail.com  Fri Jul 22 01:05:57 2016
From: pianohacker at gmail.com (Jesse)
Date: Thu, 21 Jul 2016 17:05:57 -0600
Subject: [Koha-devel] Moving on
Message-ID: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>

Friends, colleagues, and that crazy guy named Kyle,

I wanted to let you know that today will be my last day with ByWater
Solutions. I'm taking a job with a local web application shop.

I will miss working with all of you, though I plan to be involved with the
Koha community going forward.

Peace and good luck,
-- 
Jesse Weaver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160721/5b785f3c/attachment.html>

From cgdavis at uintah.utah.gov  Fri Jul 22 14:23:23 2016
From: cgdavis at uintah.utah.gov (Christopher Davis)
Date: Fri, 22 Jul 2016 06:23:23 -0600
Subject: [Koha-devel] Moving on
In-Reply-To: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
Message-ID: <CACFiFkac8CZVWntB-24hetKPuqmxcd02BGU8uZcp5WPeDcNKMw@mail.gmail.com>

Jesse,

Best of luck to you and thank you for your work on Koha.

Take care,

Christopher Davis, MLS
Systems & E-Services Librarian
Uintah County Library
cgdavis at uintah.utah.gov
(435) 789-0091 ext.261
uintahlibrary.org
basinlibraries.org
facebook.com/uintahcountylibrary
instagram.com/uintahcountylibrary


On Thu, Jul 21, 2016 at 5:05 PM, Jesse <pianohacker at gmail.com> wrote:
> Friends, colleagues, and that crazy guy named Kyle,
>
> I wanted to let you know that today will be my last day with ByWater
> Solutions. I'm taking a job with a local web application shop.
>
> I will miss working with all of you, though I plan to be involved with the
> Koha community going forward.
>
> Peace and good luck,
> --
> Jesse Weaver
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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  Fri Jul 22 14:39:40 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 22 Jul 2016 12:39:40 +0000
Subject: [Koha-devel] Moving on
In-Reply-To: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
Message-ID: <CABZfb=WDbqFTEMjrQYkU-MoZcuB8mv7aGxrcnK7uc=h3wXbg6A@mail.gmail.com>

Jesse, thanks for all you did for the project.

Good luck, enjoy your new challenges!

El jue., 21 jul. 2016 a las 20:21, Jesse (<pianohacker at gmail.com>) escribi?:

> Friends, colleagues, and that crazy guy named Kyle,
>
> I wanted to let you know that today will be my last day with ByWater
> Solutions. I'm taking a job with a local web application shop.
>
> I will miss working with all of you, though I plan to be involved with the
> Koha community going forward.
>
> Peace and good luck,
> --
> Jesse Weaver
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160722/d14e8848/attachment.html>

From barton at bywatersolutions.com  Fri Jul 22 16:11:32 2016
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Fri, 22 Jul 2016 10:11:32 -0400
Subject: [Koha-devel] Moving on
In-Reply-To: <CACFiFkac8CZVWntB-24hetKPuqmxcd02BGU8uZcp5WPeDcNKMw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
	<CACFiFkac8CZVWntB-24hetKPuqmxcd02BGU8uZcp5WPeDcNKMw@mail.gmail.com>
Message-ID: <CAMSJbVtNTLctif1xFv-CZt0FDLfFhk1BKZuNtWMc9Qx5miizuA@mail.gmail.com>

On Fri, Jul 22, 2016 at 8:23 AM, Christopher Davis <cgdavis at uintah.utah.gov>
wrote:

> Jesse,
>
> Best of luck to you and thank you for your work on Koha.
>

I'll second that in spades!

--Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160722/53eede98/attachment.html>

From kyle.m.hall at gmail.com  Sat Jul 23 12:15:21 2016
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Sat, 23 Jul 2016 06:15:21 -0400
Subject: [Koha-devel] Moving on
In-Reply-To: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
Message-ID: <CACpVHfzcPWs6J5BGsMmovdVkq4OxSWMKXA6u=yLfEizruE00RA@mail.gmail.com>

Jesse, working with you has been a pleasure and a privilege and I hope we
get a chance to collaborate again.

See you around ; )

Kyle

<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>

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 Thu, Jul 21, 2016 at 7:05 PM, Jesse <pianohacker at gmail.com> wrote:

> Friends, colleagues, and that crazy guy named Kyle,
>
> I wanted to let you know that today will be my last day with ByWater
> Solutions. I'm taking a job with a local web application shop.
>
> I will miss working with all of you, though I plan to be involved with the
> Koha community going forward.
>
> Peace and good luck,
> --
> Jesse Weaver
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160723/8679681f/attachment.html>

From kyle.m.hall at gmail.com  Sat Jul 23 12:25:37 2016
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Sat, 23 Jul 2016 06:25:37 -0400
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <579122D4.3090407@inlibro.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
	<5790FBB6.8020009@inlibro.com>
	<CABZfb=W8YXdmjuPUXE_Wub5yZZvo4JoohNBuJJtBmDRhCczndw@mail.gmail.com>
	<579122D4.3090407@inlibro.com>
Message-ID: <CACpVHfzXqhuPmN38ktCR05Rai8spj7hYr2qjwgeii7iCJuwomg@mail.gmail.com>

I think this sounds great! The one suggestion I would make is to try to
break this down into as many discretely testable bug reports a possible.
The smaller each testable unit is, the more easily tested and qa'd it is.

Kyle

<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB>

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 Thu, Jul 21, 2016 at 3:30 PM, Philippe Blouin <
philippe.blouin at inlibro.com> wrote:

> On 07/21/2016 02:23 PM, Tomas Cohen Arazi wrote:
>
> I'm all for speed improvements. But:
> - A clear backwards-compatible upgrade path needs to be set and written.
>
> Our curent script takes the content of the "old" tables to create the new
> one.  Past and future.  Is that what you mean?
> More so, I've split the work in 8 theoretical steps.  But I think it could
> be considered to offer both ways in parallel: just add the new DB table,
> slowly transfer the calls to the new library.  Just make sure the new table
> is populated on any call to modify the "old ones".
>
> - I think (because of the speed improvement) that you are realying more on
> the DB features, this needs to be discussed if it can cause trouble.
>
> Actually, that's the serious point: we're going simple SELECTs the old
> way.  With no cache or anything right now.  It's not the fact that the code
> is cut by 80% or anything (although it would be).  It's just that much
> faster to do date calculations using the DB than Perl's DateTime.
> Something like...
>
> SELECT COUNT(*) FROM discrete_calendar WHERE (date BETWEEN ? AND ?) AND
> (isopen=1)
>
> Add in opening and closing hours and it's golden.  Easily hashable and
> cachable as well.
>
> - The less you change the API, the easier is to spot regressions for the
> current blacklist-like implementation of the calendar. Tests could be
> adjusted, but it'd be interesting to have the current tests pass.
>
> I agree.  I admit I do not have a clear plan, and I know without perfect
> test coverage, this stands no chance.  More so, wasting perfectly valid old
> tests is... a waste.
>
> But again, I'm throwing a line.  I want to see if others beside us see a
> need.  I want to see if someone is already working on something that would
> conflict, etc...
>
>
> Regards
>
> Thanks a lot for the feedback!
>
>
>
> El jue., 21 jul. 2016 a las 13:43, Philippe Blouin (<
> philippe.blouin at inlibro.com>) escribi?:
>
>> Hi!
>>
>> I'm throwing a line here, and I'd just like to get a feel for the value
>> of offering some work to the community.  Mind you, the work is "big" so
>> honest responses could save us lot of wasted hours.
>>
>> We've developed a parallel calendar table to specify each individual day
>> if it's opened or not (instead of rules and exception).  We added to it the
>> opening hours, and keep a year of them in the past, and a year in the
>> future.
>> The reasonning being:
>> - We need the opening hours.  They need to vary season to seasons.  We
>> need them for hourly and minute loans.
>> - Exception and holidays and etc... are complicated.  To manage, to
>> calculate, to fix.  We need the past info as well, to calculate precisely.
>> - Performance.  Calculating with C4/Koha Calendars is sloooooooooow.  Our
>> little table cut fines.pl calculation times by 97%.  Not a typo.
>> Checkout improvement by 30-60% but metric is unreliable so take with grain
>> of salt this one.
>>
>> So before I go and write a wiki RFC, then open bugzillas, make the code
>> community acceptable (we're not using Schemas), complete it, write tests,
>> etc...  Is there an interest?  Would it answer a need (outside of our
>> clients) ?  Maybe a subset?
>>
>> All comments, suggestions, questions are welcomed.
>>
>> High regards,
>>
>> Philippe Blouin,
>> Responsable du d?veloppement informatique
>>
>> T?l.  : (888) 604-2627
>> philippe.blouin at inLibro.com
>> inLibro | pour esprit libre | www.inLibro.com
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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 (https://theke.io <http://theke.io/>)
> ? +54 9351 3513384
> GPG: B2F3C15F
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160723/b9797f1e/attachment.html>

From Katrin.Fischer.83 at web.de  Sun Jul 24 22:28:54 2016
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Sun, 24 Jul 2016 22:28:54 +0200
Subject: [Koha-devel] Koha namespace architecture - calls for discussions
In-Reply-To: <CABZfb=UhwZ1PMqrjOfZxr9A+cMGLFTXYiHKErt_eP6ofs5n3eQ@mail.gmail.com>
References: <CAJzKNY5xN0yihnhBSvC1FVzOajahgNfcr8qmCCWkUV_LyZRi1Q@mail.gmail.com>
	<CABZfb=UhwZ1PMqrjOfZxr9A+cMGLFTXYiHKErt_eP6ofs5n3eQ@mail.gmail.com>
Message-ID: <d15869e0-5b8a-1c9b-5224-4eaeb29ac065@web.de>


>     5/ patronflags?
>     Any ideas what we could do with C4::Members::patronflags? :)

Hm, maybe Koha::Patrons::Permissions?





From Katrin.Fischer.83 at web.de  Sun Jul 24 22:42:51 2016
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Sun, 24 Jul 2016 22:42:51 +0200
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <5790FBB6.8020009@inlibro.com>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
	<5790FBB6.8020009@inlibro.com>
Message-ID: <ceca073c-4797-9b73-2aa6-69b1784318c0@web.de>

Hi Philippe,

thx for trying to get things moving again - I know there are quite a lot
calendar related bugs to be found in bugzilla.

Can you explain a bit about how this would change the GUI for the users?
Do you have to keep it up to date or does the table get filled
automatically for recurring events?

I am a bit concerned about the limitation of one year into the past and
one year into the future. What happens if a due date goes beyond that or
an item is overdue before that?

Katrin

Am 21.07.2016 um 18:43 schrieb Philippe Blouin:
> Hi!
> 
> I'm throwing a line here, and I'd just like to get a feel for the value
> of offering some work to the community.  Mind you, the work is "big" so
> honest responses could save us lot of wasted hours.
> 
> We've developed a parallel calendar table to specify each individual day
> if it's opened or not (instead of rules and exception).  We added to it
> the opening hours, and keep a year of them in the past, and a year in
> the future.
> The reasonning being:
> - We need the opening hours.  They need to vary season to seasons.  We
> need them for hourly and minute loans.
> - Exception and holidays and etc... are complicated.  To manage, to
> calculate, to fix.  We need the past info as well, to calculate precisely.
> - Performance.  Calculating with C4/Koha Calendars is sloooooooooow. 
> Our little table cut fines.pl calculation times by 97%.  Not a typo. 
> Checkout improvement by 30-60% but metric is unreliable so take with
> grain of salt this one.
> 
> So before I go and write a wiki RFC, then open bugzillas, make the code
> community acceptable (we're not using Schemas), complete it, write
> tests, etc...  Is there an interest?  Would it answer a need (outside of
> our clients) ?  Maybe a subset? 
> 
> All comments, suggestions, questions are welcomed.
> 
> High regards,
> 
> Philippe Blouin,
> Responsable du d?veloppement informatique
> 
> T?l.  : (888) 604-2627
> philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
> 
> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
> 
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 chris at bigballofwax.co.nz  Sun Jul 24 23:56:26 2016
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 25 Jul 2016 09:56:26 +1200
Subject: [Koha-devel] Moving on
In-Reply-To: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
Message-ID: <CA+95qVRsSZYK7vkrej25D4tgj=nGU3gF_WvEpGzoLF=Rmf5Nbw@mail.gmail.com>

On 22 July 2016 at 11:05, Jesse <pianohacker at gmail.com> wrote:
> Friends, colleagues, and that crazy guy named Kyle,
>
> I wanted to let you know that today will be my last day with ByWater
> Solutions. I'm taking a job with a local web application shop.
>
> I will miss working with all of you, though I plan to be involved with the
> Koha community going forward.
>
> Peace and good luck,

Kia ora Jesse

I'm pretty sure we first talked on IRC in either late 2007 or early
2008, your first message to the devel list I can find is
from Sat Feb 16 18:57:35 CET 2008 and it was about the issuing rules
page. http://lists.koha-community.org/pipermail/koha-devel/2008-February/029979.html
I remember being super impressed that a 16 (or 15?) year old was so on
to it, and so willing to listen and learn.

To quote myself talking about mentoring relationships [they] "have all
evolved from people asking questions on IRC or in the mailing lists.
Then following up the answer with a thank you; usually the ?thank you'
is what gets me hooked."
http://www.itworld.com/article/2768355/open-source-tools/mentoring-in-open-source-communities--what-works--what-doesn-t-.html
Jesse you never ever once forgot to say thank you, and I hope that I
was a small part of helping you become the awesome man you are.

We first met in person at Kohacon09 in Plano Texas, and this is where
we also need to thank your parents for allowing you to come meet up
with a bunch of weird librarians and programmers you hadn't met ;)
https://www.flickr.com/photos/37713236 at N03/3471061290/
And most recently in Berlin and Thessaloniki
https://www.flickr.com/photos/ranginui/26941372043/
Still discussing technical things with other devs, the difference is
this time you were legal to drink a beer ;)

I know you will do great things at the new place you are working at,
but I also know you have the Koha bug now, and you'll be back ;)

All the best, keep in touch

Chris

From dcook at prosentient.com.au  Mon Jul 25 02:40:12 2016
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 25 Jul 2016 10:40:12 +1000
Subject: [Koha-devel] Moving on
In-Reply-To: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
Message-ID: <008b01d1e60d$1ab2e4f0$5018aed0$@prosentient.com.au>

I haven?t known you as long as Chris, but I?ll never forget standing with Katrin at Kohacon13 in the hotel lobby and trying to figure out if you were pianohacker or not :p. It was a pleasure meeting in person back then, and I?ve always been glad to bump into you on IRC. 

 

Sorry to see you go, but best of luck with your new opportunity!



David Cook

Systems Librarian

 

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Jesse
Sent: Friday, 22 July 2016 9:06 AM
To: koha-devel at lists.koha-community.org; koha koha <koha at lists.katipo.co.nz>
Subject: [Koha-devel] Moving on

 

Friends, colleagues, and that crazy guy named Kyle,


I wanted to let you know that today will be my last day with ByWater Solutions. I'm taking a job with a local web application shop.

I will miss working with all of you, though I plan to be involved with the Koha community going forward.

Peace and good luck,

-- 

Jesse Weaver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160725/e06084d4/attachment.html>

From arslanone at gmail.com  Mon Jul 25 04:46:32 2016
From: arslanone at gmail.com (Arslan Farooq)
Date: Mon, 25 Jul 2016 07:46:32 +0500
Subject: [Koha-devel] [Koha]  Moving on
In-Reply-To: <CACFiFkac8CZVWntB-24hetKPuqmxcd02BGU8uZcp5WPeDcNKMw@mail.gmail.com>
References: <CAEjTV=8NVVj2r4R54O6rTgeLR1b_9GaBqgVW8beeiO+tD979cw@mail.gmail.com>
	<CACFiFkac8CZVWntB-24hetKPuqmxcd02BGU8uZcp5WPeDcNKMw@mail.gmail.com>
Message-ID: <E4BD2E89-4A90-40EC-B805-B9D3C76215D6@gmail.com>

Hello Jesse,

We've never met but I've heard great things about you.

Best of luck and best wishes man!

Arslan



>On Thu, Jul 21, 2016 at 5:05 PM, Jesse <pianohacker at gmail.com> wrote:
>> Friends, colleagues, and that crazy guy named Kyle,
>>
>> I wanted to let you know that today will be my last day with ByWater
>> Solutions. I'm taking a job with a local web application shop.
>>
>> I will miss working with all of you, though I plan to be involved
>with the
>> Koha community going forward.
>>
>> Peace and good luck,
>> --
>> Jesse Weaver

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From philippe.blouin at inlibro.com  Mon Jul 25 14:32:11 2016
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Mon, 25 Jul 2016 08:32:11 -0400
Subject: [Koha-devel] Pre-RFC on new discrete calendar
In-Reply-To: <ceca073c-4797-9b73-2aa6-69b1784318c0@web.de>
References: <CAPK2MLt_6JKXFp+RkDT2cDX+Uivk=Yzat=eXywpHbhEpGXnwUw@mail.gmail.com>
	<CAAh7Ud=qXHL50rdb6eGw-b_PVaRHxvNT_DrQ47NzegDTpX1Dtg@mail.gmail.com>
	<CABZfb=X7Pb7ryOTT9yPCKSgBJ9pMoHk1Ec8m5UQomL7c2AdySQ@mail.gmail.com>
	<CAAh7Udkr3LWnPNhNbnTPMwMSKWdt8xbz61t9YAyG_7FPG=JJxw@mail.gmail.com>
	<5790FBB6.8020009@inlibro.com>
	<ceca073c-4797-9b73-2aa6-69b1784318c0@web.de>
Message-ID: <579606CB.9030201@inlibro.com>

Good afternoon Katrin!

Let's start with the backend: this is just a simple script that fills 
the calendar ahead of time (waaay ahead of time) to allow the user to 
modify schedules easily.  1 year is just a hardcoded value, it could as 
well be an argument allowing any number of days in the future.  Same for 
the past: during updatedatabase, this creates one but could create two 
years in the past based on the info in the current calendar tables.  In 
the end, the point is to have a table entry for each day, specifying 
which day it WAS opened (for hourly fine calculation) and which day it 
will be opened (for hourly checkout or just for displaying the library 
open hours on the OPAC).  Going a year in the future, things are a bit 
dumb when creating, but always replicate the week before, except for 
items with notes (holiday) that are fetched on the calendar year a year 
before.  Then the librarian has plenty of time to adjust anything.

Which brings us to the UI.  Mine is ugly, but it would be easy to create 
a nice one AND SIMPLE one (coding) and powerful one (for users).  With 
that simple backend, it's very easy to simply allow multiple selections 
in the calendar widget, the modify opening hours, or holiday close with 
a note.  Or better: select a week anywhere in the calendar, then copy 
that to a given range.  3 days, a month, 3 months...   Very simple in 
the UI, very few clicks.  Very simple to code in the backend.

So in the end, recovering the original work or Kyle's work or defining 
new standard, we have a calendar page with a simple calendar and below 
it a few edit box (opening hours, closing, notes, closed checkbox) and a 
apply button.  On the right, like right now, we can display all "special 
dates", which are the ones with a "note" entry.  In yellow those that 
are on days still opened, in pink those days that are marked as closed.  
Of course, all UI schemes are very open to suggestion.  But it would be 
simple and naturally intuitive.

THEN we get to the performance benefits I'm striving for....

Right now, my first step would be to create a patch that creates the new 
table and modify the Koha/C4 Calendar modules to seed the new one with 
any modification of the old ones.  So no impact on current behavior.  
Then second step would be to create the new UI, without touching the old 
one.  THEN next step would be to transfer the functionnality usages.  
Basically in reverse order of what I have available right now.  :-)

Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
On 07/24/2016 04:42 PM, Katrin Fischer wrote:
> Hi Philippe,
>
> thx for trying to get things moving again - I know there are quite a lot
> calendar related bugs to be found in bugzilla.
>
> Can you explain a bit about how this would change the GUI for the users?
> Do you have to keep it up to date or does the table get filled
> automatically for recurring events?
>
> I am a bit concerned about the limitation of one year into the past and
> one year into the future. What happens if a due date goes beyond that or
> an item is overdue before that?
>
> Katrin
>
> Am 21.07.2016 um 18:43 schrieb Philippe Blouin:
>> Hi!
>>
>> I'm throwing a line here, and I'd just like to get a feel for the value
>> of offering some work to the community.  Mind you, the work is "big" so
>> honest responses could save us lot of wasted hours.
>>
>> We've developed a parallel calendar table to specify each individual day
>> if it's opened or not (instead of rules and exception).  We added to it
>> the opening hours, and keep a year of them in the past, and a year in
>> the future.
>> The reasonning being:
>> - We need the opening hours.  They need to vary season to seasons.  We
>> need them for hourly and minute loans.
>> - Exception and holidays and etc... are complicated.  To manage, to
>> calculate, to fix.  We need the past info as well, to calculate precisely.
>> - Performance.  Calculating with C4/Koha Calendars is sloooooooooow.
>> Our little table cut fines.pl calculation times by 97%.  Not a typo.
>> Checkout improvement by 30-60% but metric is unreliable so take with
>> grain of salt this one.
>>
>> So before I go and write a wiki RFC, then open bugzillas, make the code
>> community acceptable (we're not using Schemas), complete it, write
>> tests, etc...  Is there an interest?  Would it answer a need (outside of
>> our clients) ?  Maybe a subset?
>>
>> All comments, suggestions, questions are welcomed.
>>
>> High regards,
>>
>> Philippe Blouin,
>> Responsable du d?veloppement informatique
>>
>> T?l.  : (888) 604-2627
>> philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>>
>> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://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
> http://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: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160725/ba2cd8f0/attachment.html>

From 201451032 at iiitvadodara.ac.in  Fri Jul 29 07:52:36 2016
From: 201451032 at iiitvadodara.ac.in (ADITYA RAJ)
Date: Fri, 29 Jul 2016 11:22:36 +0530
Subject: [Koha-devel] Regarding the implementation of recommender system in
	koha
In-Reply-To: <CABscR_-L+cwn+hdGJi8Jwza_SyYYZMu3eFkU6a4=PdHKX3c7VQ@mail.gmail.com>
References: <CABscR__DCQTrDEZWpUou9p8+cUR3qne5u810Asrvm7NsQQai9A@mail.gmail.com>
	<CABscR_8YDEL0MM1GFJv=N0atmiaDrKvUzyAc3=aOgpCp93yrvA@mail.gmail.com>
	<CABscR__AGRNxS2tcQ8yxRMPiq+EeQ4R2Nf2_9agx2u9nRMY5sg@mail.gmail.com>
	<CABscR_8qEvM0b8gJQPXC7O8d9c+vxLh09vuXnYPt69=U65psyg@mail.gmail.com>
	<CABscR_-L+cwn+hdGJi8Jwza_SyYYZMu3eFkU6a4=PdHKX3c7VQ@mail.gmail.com>
Message-ID: <CABscR_82Jr_u_BHGM_-X3qritrC2WhoQpngTthWz9+g-W0KYPg@mail.gmail.com>

Sir,In my college I am working on recommender system project and I want to
implement it in koha search so I need some help
Hoping positive response from you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160729/f582b596/attachment.html>

From mirko at abunchofthings.net  Fri Jul 29 10:56:38 2016
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Fri, 29 Jul 2016 10:56:38 +0200
Subject: [Koha-devel] General IRC Meeting 3 August 2016 / Kohacon 2017
	bidder information
Message-ID: <b15c9a04-686a-4a3a-ae99-a3aa8e194ed5@abunchofthings.net>

Hi everyone,

the next general IRC meeting is next week, 3 August 2016, 10:00 UTC.

Conversion to your local time:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20160803T10

You can find the agenda here:
https://wiki.koha-community.org/wiki/General_IRC_meeting_3_August_2016

This is the last meeting before we close bidding to host Kohacon
2017. It would be nice if bidders would join us at the meeting and
tell a little about their plans.

If the meeting is not an option, please send a message to the
mailing list explaining that you are still interested in hosting
Kohacon 2017, and please update your proposals in the Koha wiki now
if necessary: Narrow down the proposed dates if possible, update
conference locations, add contact emails(!).
https://wiki.koha-community.org/wiki/KohaCon17_Proposals

We are still open for proposals to host Kohacon 2017 until 10 August
2016 UTC.

Cheers,

Mirko


--

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net
http://meinkoha.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160729/e8dffd19/attachment.pgp>

From mirko at abunchofthings.net  Fri Jul 29 19:28:51 2016
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Fri, 29 Jul 2016 19:28:51 +0200
Subject: [Koha-devel] koha-common 16.06~git+20160729190213.ed61bd9b
Message-ID: <a223cc2d-96e3-be7a-dd20-a40747bf8f3e@abunchofthings.net>

Hello everyone,

I have uploaded a new master package to the Koha unstable repository.

Have a nice weekend,

Mirko


--

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net
http://meinkoha.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160729/f860174e/attachment.pgp>

From tomascohen at gmail.com  Fri Jul 29 20:31:41 2016
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 29 Jul 2016 18:31:41 +0000
Subject: [Koha-devel] koha-common 16.06~git+20160729190213.ed61bd9b
In-Reply-To: <a223cc2d-96e3-be7a-dd20-a40747bf8f3e@abunchofthings.net>
References: <a223cc2d-96e3-be7a-dd20-a40747bf8f3e@abunchofthings.net>
Message-ID: <CABZfb=XGXOAzqVxtrw7S2_s2aGMDbt6cyosQ-PB7uDHVL-+vww@mail.gmail.com>

+1

El vie., 29 jul. 2016 14:29, Mirko Tietgen <mirko at abunchofthings.net>
escribi?:

> Hello everyone,
>
> I have uploaded a new master package to the Koha unstable repository.
>
> Have a nice weekend,
>
> Mirko
>
>
> --
>
> Mirko Tietgen
> mirko at abunchofthings.net
> http://koha.abunchofthings.net
> http://meinkoha.de
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160729/68ce568c/attachment.html>

From mirko at abunchofthings.net  Fri Jul 29 22:23:18 2016
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Fri, 29 Jul 2016 22:23:18 +0200
Subject: [Koha-devel] Deprecation of Wheezy & packages [was koha-common
 16.06~git+20160729190213.ed61bd9b]
In-Reply-To: <a223cc2d-96e3-be7a-dd20-a40747bf8f3e@abunchofthings.net>
References: <a223cc2d-96e3-be7a-dd20-a40747bf8f3e@abunchofthings.net>
Message-ID: <c2b16513-86af-590a-f6b4-3036b39538b1@abunchofthings.net>

Hi,

I forgot to mention, this is the first master package I built
against Jessie. It includes dependencies not available in Wheezy,
namely libserial-encoder-perl and libserial-decoder-perl. Others
will follow.

I will continue building stable and oldstable against Wheezy until
16.11, but as Wheezy is deprecated by the Koha community and our
support will officially end with the release of 16.11, I will only
backport security related packages to Wheezy. I have just done that
with libwww-csrf-perl libcrypt-random-seed-perl and
libbytes-random-secure-perl.

If somebody has good reason to maintain a Wheezy-safe version of
Koha beyond 16.11 _and is willing to actively maintain it_, I will
consider supporting it with packages.

We have a "nowheezy" keyword in Bugzilla now, I will try to tag
things with dependencies not available in Wheezy.

Cheers,

Mirko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160729/33fe1add/attachment.pgp>

From kohanews at gmail.com  Sat Jul 30 02:59:43 2016
From: kohanews at gmail.com (kohanews)
Date: Fri, 29 Jul 2016 17:59:43 -0700
Subject: [Koha-devel] Koha Community Newsletter: July 2016
Message-ID: <a0209837-7e78-7cc0-b740-66b3568de693@gmail.com>

Fellow Koha users:

The Koha Community Newsletter for June 2016 is here:
https://koha-community.org/koha-community-newsletter-july-2016/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

Thanks!

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160729/9404f624/attachment.html>