Re: [Koha-devel] Anybody still using tarballs?

[Galen Charlton via Koha-devel]

Hi,

On Tue, Nov 7, 2023 at 3:22 PM Jonathan Druart via Koha-devel <
koha-devel@lists.koha-community.org> wrote:

> I am suggesting removing the tarball from our release process. I don't
> think anybody is using it anyway.
> It's extra work for RMaints, and it does not seem necessary.
>

I know that there are some Koha libraries running on RedHat-derived
distributions. While such sites could in principle maintain their
installations from Git checkouts, they are a constituency of likey tarball
users.

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] borrower_message_preference_id reaches limit - quickfix?

[Galen Charlton]

Hi,

On Wed, Jan 4, 2023 at 4:28 AM Magnus Enger  wrote:
> Bug 32556 - borrower_message_preference_id reaches limit
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32556
>
> Has anyone else run into this, and found a quickfix that works?
>
> I tried dumping the database, changing the id columns from INT to
> BIGINT, but got a foreign key error when loading the database back in.

I responded in the bug, but it is possible to remove and recreate the
specific foreign key constraint that references
borrower_message_preference_id when changing the type of that column and
its referrer.

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] REST API should not advertise required permissions

[Galen Charlton]

Hi,

On Tue, Jan 3, 2023 at 7:58 PM David Cook  wrote:
> It seems to me that we should just stop at “Authorization failure”. While
it
> might be helpful for a dev to know what the required permissions are,
>  I think it would also be overly helpful for an attacker to know what
> permissions are required too, no?

I don't feel strongly about it, but lean towards including the details for
the sake of anybody trying to use the API. After all, the game is already
up if the attacker is able to grant additional permissions to the service
account.

This may be a stretch, but another advantage of including the details is to
reduce any temptation to assign the superlibrarian permission to a service
account "just to get it working".

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Fundamental flaw in Koha REST API

[Galen Charlton]

Hi,

On Mon, Dec 5, 2022 at 5:40 PM David Cook  wrote:
> At the moment, it’s not widely used by Koha itself, so I don’t think
> it will be hard to remove from Koha, but any third-party integrations
> would need to refactor to use a different option.

This might not be a huge factor, though of course removing that header
should go through a deprecation procedure.

Specifically, upon skimming the results of a GitHub search of
"x-koha-query", the only uses I found outside of Koha itself were in
plugins published by a couple active community members.

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] debian.koha-community.org refusing connections from server

[Galen Charlton]

Hi,

On Tue, May 10, 2022 at 3:12 AM  wrote:

> Who manages the server that hosts debian.koha-community.org? It looks
> like it’s actively refusing connections from one of my Koha servers.
>
>
>
> Err:9 http://debian.koha-community.org/koha 20.11 InRelease
>
>   Could not connect to debian.koha-community.org:80 (67.220.127.145),
> connection timed out
>
>
>
> I was able to connect just fine from a different IP address, and that
> server can contact many other Apt repos.
>

That would be me. Please let me know the IP address of the server that was
getting blocked.

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Biblio Auto-Increment location

[Galen Charlton]

Hi Bruce,

On Wed, May 4, 2022 at 4:16 PM Chris Cormack  wrote:
> There's a lot we can code around, cataloguing cats is definitely not one
:)

Is this the (adorable) miscreant in question?
https://twitter.com/augustanalib/status/973622037276012545

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Thoughts on reloading Koha plugins

[Galen Charlton]

Hi,

On Wed, May 26, 2021 at 1:17 AM  wrote:

> Hmm interesting. I see instructions on setting up Wordpress with FastCGI
> but no comments about any impact that would have on plugins. Maybe they
> just don’t worry about it the same way most Koha folk don’t worry about it
> hehe.
>

As I recall, Zend Opcache has various settings to control if and when it
will recompile the PHP scripts in caches. Depending on what settings you
choose, in a FastCGI environment it can periodically check to see if a
script has been updated and update the cache if need be - or, if you
choose, never revalidate the cache, in which case you'd need to reload or
restart php-fpm after changing code.

Also, WordPress has code that tries to clear opcache. [1, 2]

[1]
https://developer.wordpress.org/reference/functions/wp_opcache_invalidate/
[2] https://core.trac.wordpress.org/ticket/36455

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Koha Community Wordpress Accounts person

[Galen Charlton]

Hi,

I'll set up an account and send details to Michael directly.

Regards,

Galen

On Mon, Nov 30, 2020 at 2:02 PM Koha News  wrote:

> Not sure who is managing the Koha Community Wordpress installation but
> we need an account created for Michael Kuhn who is going to be taking on
> the newsletter.
>
> Thank you!
>
> Chad
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>


-- 
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Cleaning git project list

[Galen Charlton]

Hi,

On Tue, Sep 8, 2020 at 5:26 AM Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:
> wip/koha-equinox.git Equinox work in progress     Galen Charlton

I confirm that this can go away.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] KC apt server, time for an upgrade?

[Galen Charlton]

Hi,

On Thu, Jul 23, 2020 at 1:12 PM Galen Charlton 
wrote:
> Sure. I will proceed with bumping up the VM's Debian version over the
next few days.

It's now running Debian 8; I'll bump it up to 9 over the weekend.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] KC apt server, time for an upgrade?

[Galen Charlton]

Hi,

On Thu, Jul 23, 2020 at 12:34 AM Mason James  wrote:

> can we make a plan to get the VM upgraded (or the repo moved) to
> debian/ubuntu stable
>

Sure. I will proceed with bumping up the VM's Debian version over the next
few days.

Regards,

Galen
-- 
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Barcode duplicates is possible

[Galen Charlton]

Hi,

On Wed, Jan 30, 2019 at 11:05 AM Owen Leonard  wrote:
> Is there any form data *shouldn't* trim?

The only cases I can think of where leading or trailing whitespace should
be retained would be certain fixed fields in MARC records and subfields in
the the MARC21 010 field.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] removing some projects from git.koha-community.org

[Galen Charlton]

Hi,

On Wed, Nov 14, 2018 at 8:48 AM Paul Poulain 
wrote:
> wip/koha-equinox.git Equinox work in progress     Galen Charlton
5 years ago

This one is disused and from Equinox's point of view does not need to be
retained.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] no acces to debian.koha-community.org

[Galen Charlton]

Hi,

It is now back up.

Regards,

Galen

On Fri, Dec 1, 2017 at 9:37 AM, Galen Charlton
<g...@equinoxinitiative.org> wrote:
> Hi,
>
> I'm taking a look at this now; the VM appears to have fallen over after a DOS.
>
> Regards,
>
> Galen
>
> On Fri, Dec 1, 2017 at 9:36 AM, Laurent Ducos
> <laurent.du...@biblibre.com> wrote:
>> always closed, Port 80 seems closed
>>
>> telnet debian.koha-community.org 80
>> Trying 67.220.127.145...
>> 
>> timeout
>> Laurent Ducos
>> Administrateur Systèmes et Réseaux
>> 0974770716
>> 1 décembre 2017 15:28 "Michael Kuhn" <m...@adminkuhn.ch> a écrit:
>>> Hi
>>>
>>>>> Since about 1 hour I do not have access to debian.koha-community.org from 
>>>>> our public ip
>>>>> 91.121.55.79
>>>>> Can you give us access again please?
>>>>> since others ip everything is ok
>>>
>>> Right now, http://debian.koha-community.org can be accessed again.
>>>
>>> Best wishes: Michael
>>> --
>>> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>>> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>>> T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
>>> ___
>>> Koha-devel mailing list
>>> Koha-devel@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@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/
>
>
>
> --
> Galen Charlton
> Infrastructure and Added Services Manager
> Equinox Open Library Initiative
> phone:  1-877-OPEN-ILS (673-6457)
> email:  g...@equinoxinitiative.org
> web:  https://equinoxInitiative.org
> direct: +1 770-709-5581
> cell:   +1 404-984-4366



-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] no acces to debian.koha-community.org

[Galen Charlton]

Hi,

I'm taking a look at this now; the VM appears to have fallen over after a DOS.

Regards,

Galen

On Fri, Dec 1, 2017 at 9:36 AM, Laurent Ducos
<laurent.du...@biblibre.com> wrote:
> always closed, Port 80 seems closed
>
> telnet debian.koha-community.org 80
> Trying 67.220.127.145...
> 
> timeout
> Laurent Ducos
> Administrateur Systèmes et Réseaux
> 0974770716
> 1 décembre 2017 15:28 "Michael Kuhn" <m...@adminkuhn.ch> a écrit:
>> Hi
>>
>>>> Since about 1 hour I do not have access to debian.koha-community.org from 
>>>> our public ip
>>>> 91.121.55.79
>>>> Can you give us access again please?
>>>> since others ip everything is ok
>>
>> Right now, http://debian.koha-community.org can be accessed again.
>>
>> Best wishes: Michael
>> --
>> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>> T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
>> ___
>> Koha-devel mailing list
>> Koha-devel@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@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/



-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Gender-neutral pronouns

[Galen Charlton]

Hi,

On Thu, Apr 20, 2017 at 10:59 AM, Paul Poulain
<paul.poul...@biblibre.com> wrote:
> I'll probably be poorly ranked here, but in my opinion there are more
> important things to fix in Koha... (randomly chosen: clean the wiki from
> severely outdated pages, test one of the 205 patches waiting for sign-off,
> improve documentation, investigate why we have 10 blockers or critical bugs
> open -without a patch-, one of them BZ14731 being >1yr old)

Well, folks remain free to set their personal priorities in how they
choose to contribute to Koha. Trying to be more inclusive by measuring
our words more carefully does not preclude working on bugs or updating
the wiki... and may also result in more potential contributors
deciding to stick around and pitch in.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] [Koha] Redundant infrastructure for Koha

[Galen Charlton]

Hi,

On Mon, Nov 7, 2016 at 4:36 PM, Michael Hafen <michael.ha...@washk12.org> wrote:
> Has anyone tried access Zebra through a network socket instead of the unix
> one?  I was under the impression that that was possible.

It is, and it's as easy as changing the following lines in koha-conf.xml from:

unix:/var/run/koha/SITE/bibliosocket
unix:/var/run/koha/SITE/authoritysocket

to

tcp:HOST_OR_IP:PORT
tcp:HOST_OR_IP:ANOTHER_PORT

Of course, depending on how you arrange things, local tweaks to the
indexer jobs would be required to ensure that all of the copies of the
Zebra databases got updated.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] SPAM in bugzilla: what do we do ?

[Galen Charlton]

Hi,

On Thu, Sep 8, 2016 at 9:13 AM, Jonathan Druart
<jonathan.dru...@bugs.koha-community.org> wrote:
> The later:
> 17276, 17242, 17219, 17199, 17071, 17070, etc.

I have disabled the BZ accounts that filed those bugs, none of which
had any activity other than creating the spam.

If this turns out to be more than just a blip, there appears to be at
least one anti-spam extension we could try [1].

[1] https://github.com/mozilla-bteam/bmo/tree/master/extensions

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Frameworks / DB constraints

[Galen Charlton]

Hi,

On Tue, Apr 19, 2016 at 11:16 AM, Tajoli Zeno <z.taj...@cineca.it> wrote:
> I'm agree on solution proposed by Jesse: creating the foreign key with ON
> DELETE SET NULL.

At the moment, biblio.frameworkcode doesn't permit NULL values, and
InnoDB doesn't support ON DELETE SET DEFAULT.  That doesn't mean that
we couldn't do more work so that frameworkcode IS NULL is fully
supported, but it's not *just* a matter of adding the FK.

I'm more in favor of either:

- adding a FK that does ON DELETE RESTRICT. For most databases, this
would require adding a row to biblio_framework whose frameworkcode is
the empty string.
- having the business logic take care of falling back to the default
framework when necessary.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Galen Charlton]

Hi,

On Thu, Mar 3, 2016 at 7:02 AM, Mark Tompsett <mtomp...@hotmail.com> wrote:
> (a) removing $VERSION (except from Koha.pm, right?)

Right.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Galen Charlton]

Hi,

On Thu, Mar 3, 2016 at 4:08 AM, Jonathan Druart
<jonathan.dru...@bugs.koha-community.org> wrote:
> Well, they all can be removed with 2 sed basically.

Agreed, it wouldn't be a big deal to remove them in one fell swoop.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Galen Charlton]

Hi,

On Wed, Mar 2, 2016 at 9:56 AM, Jonathan Druart
<jonathan.dru...@bugs.koha-community.org> wrote:
> What are your thoughts? Are you more a, b, c, d or ... e?

I'm in favor of option a (remove $VERSION from internal modules) or
option e (drop PERL12 outright, but don't necessarily bother to remove
$VERSION from the existing modules).  I take this position on the
following basis:

- we don't explicitly promise that C4:: and Koha:: provide a _public_ API
- no, really, we don't; if we did, we would have been taking much more
care about keeping function and method signatures stable the past
decade
- any third-party code that nonetheless relies on Perl modules in C4::
and Koha:: should just check $Koha::VERSION
- if we want to provide a public API via a set of Perl modules, we're
of course free to do so, but should then keep questions of API
versioning segregated to a special namespace
- in light of all of the above considerations, any of the other
options requires effort that doesn't solve a particular problem

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Introduce the use of Grunt or Gulp?

[Galen Charlton]

Hi,

On Tue, Feb 9, 2016 at 5:57 PM, Owen Leonard <oleon...@myacpl.org> wrote:
> Removing the generated files from git makes sense from a front-end
> developer's point of view, but I wonder if that doesn't create too
> many problems for packaging/installation

As far as *packaging* is concerned... I'd just as soon that no
generated files be retained in Git, and that we rely on the build
mechanism to generate them.

> as well as complicate things
> for developers who don't want to mess with generating those files when
> they're not touching the interface?

The tricky part is ongoing updates, although Jake (and Grunt and Gulp)
do have the ability to set up "watch tasks", meaning that it's
probably possible to set something up so that recompiling/reuglify-ing
can happen automatically.  Of course, some additional developer
documentation would need to be written.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Introduce the use of Grunt or Gulp?

[Galen Charlton]

Hi,

On Sun, Feb 7, 2016 at 8:53 PM, Owen Leonard <oleon...@myacpl.org> wrote:
> I have some experience with Grunt, and have heard good things about
> Gulp. Has anyone else used either in their non-Koha projects?

Grunt is used by Evergreen's new web staff interface; while I can't
claim to be an expert in it, it gets the job done.

> Adopting them would introduce a little more complexity to the process
> of making client-side changes to Koha, and to be honest I'm not sure
> of the right way to incorporate the tools into our workflow.

>From a packaging point of view... I ended up down a rabbit hole. Grunt
itself is not packaged for Debian due to a long-standing issues with
one of its own devDependencies, JSHint [1]. I don't see any signs that
Gulp is packaged either.

Using Grunt would therefore present a problem: it would require a
build dependency that is not itself packaged for Debian.  I note that
Debian's package of jQuery includes a custom build script to avoid
using Grunt.

Jake [2] *is* packaged for Debian -- would that work for you as an
alternative, Owen?

> If there is interest I'd be happy to submit a patch introducing the
> process to the OPAC as a demonstration.

+1 for doing something, but see above.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727
[2] https://github.com/jakejs/jake

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices

[Galen Charlton]

Hi,

On Fri, Feb 5, 2016 at 2:53 PM, Kyle Hall <kyle.m.h...@gmail.com> wrote:
> I think if we are going to go with b, we should have the freedom to not be
> beholden to all the oddities and cruft of the current syntax. For this
> reason I am a fan of b.

+1 to b.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Spam in IRC

[Galen Charlton]

Hi,

On Fri, Feb 5, 2016 at 2:35 AM, Mirko Tietgen <mi...@abunchofthings.net> wrote:
> It would be nice to have somebody with op
> rights for EU mornings.

Following discussion in #koha this morning, I've added Mirko to the
list of folks able to become op.  For reference, the list now stands
at:

1: gmcharlt MASTER
2: rangi MASTER
3: slef MASTER
4: wizzyrea MASTER
5: bag CHANOP
6: cait CHANOP
7: chris_n CHANOP
8: drojf CHANOP
9: jcamins CHANOP
10: magnuse CHANOP

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] RFC for a really new stuff : sharing data worldwide

[Galen Charlton]

Hi,

On Mon, Feb 1, 2016 at 7:27 AM, Frédéric Demians <frede...@tamil.fr> wrote:
> Do we really need a Git repo for translation files since the authoring
> of translated strings is managed outside Git in Pootle?

I think there's some value in continuing to have one:

- in the (of course unlikely) event that the Pootle server completely
fails and cannot be restored, such a repository would serve as a
backup of last resort.  Likewise for the (even more unlikely) event
that somebody does major vandalism on a translation, as Pootle itself
does not have version control.
- the repository would enable reproducing a package or tarball, which
in turn would be useful for tracking down the occasional bug that
stems from an issue with one of the PO files.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] KohaCon16 - Registrations & Call for proposals Open

[Galen Charlton]

Hi,

On Mon, Jan 25, 2016 at 6:04 AM, Γιάννης Κουρμούλης <ikour...@lib.auth.gr>
wrote:
>
> Developers, technical support staff, librarians are invited to share their
> experience by contributing with a presentation proposal based on their
> knowledge, ideas, best practices and even mistakes! (Please note that all
> presentations will be in English).
>

Will proposals for remote presentations (i.e., via webinar) be considered?

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Merge borrowers and deletedborrowers tables

[Galen Charlton]

Hi,

On Wed, Jan 13, 2016 at 11:23 AM, Jonathan Druart
<jonathan.dru...@bugs.koha-community.org> wrote:
> Some of the existing constraints are wrong, some does not exist.
> On the 3 bug reports (see original message), I have submitted patches
> to add/fix the FK constraint, but we will loose data.
> The big advantage is... not to loose these data :)

That is not an unambiguous advantage: one's "losing" patron data is
another's "better protecting patron privacy".  Also, merging the two
tables will impose a cost on every user that has written reports that
query the borrowers table and will be faced with the task of
determining if they need to tack on "AND NOT deleted" clauses to the
queries.

That said, in Evergreen patron records do have a boolean flag that
expresses logical deletion status. That approach has generally worked,
but at the cost of requiring more code to fully delete and/or
anonymize records for patrons who no longer have any relationship with
the library.

Overall, I'm neutral on the design question of using one table or two;
I'm more dubious about the potential for disruption if we make a
change, since we're not starting from scratch here.

I note that the three bugs you've cited are concerned with the
deletion of *staff* user accounts.  A more minimal change might be to
treat staff accounts specially and devise a way to mark them inactive
instead of deleting them.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Hide records on Leader 05 = d in OPAC

[Galen Charlton]

Hi,

On Fri, Jan 15, 2016 at 12:46 AM, David Cook <dc...@prosentient.com.au> wrote:
> I like the idea of just deleting records directly, but I think it's
> more complex than it appears at first glance. It's not just an
> issue with OAI-PMH either really. It's an issue any time you
> try to delete a record without providing feedback to an end-user.

I've got a question for you: for the specific project you're coding
for, which ends do you control? The Koha instance, the data provider
publishing via OAI-PMH, or both?

To make a general point: yep, there are definitely edge cases and
error conditions to consider when implementing a mechanism by which a
third party can specify that records should be deleted in a Koha
database. Some of those might be better solved by policy rather than
code; for example, if the OAI-PMH provider in some sense "owns" the
records that Koha ingests from it, does the Koha library need to a
have policy of not adding items to such records?  If so, it might be
appropriate to add an option that specifies that bib deletions are to
forcibly cascade.

Conversely, if it *is* legitimate for the Koha user to add items to
those records, does that mean that the OAI-PMH provider no longer has
"ownership"?

To make another general point: I think it would be better for the
consequences of record deletion to be handled *within the context of
OAI-PMH harvesting* (or more generally, mechanisms to sync records
with an external provider), but *not* to have those consequences spill
over for users who are not doing such harvesting as all.  Your
original proposal to unconditionally hide Leader/05='d' records from
the public catalog would be an example of such spillover.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Hide records on Leader 05 = d in OPAC

[Galen Charlton]

Hi,

On Sun, Jan 10, 2016 at 8:44 PM, David Cook <dc...@prosentient.com.au> wrote:
> We can’t necessarily rely on all Koha instances running this cronjob, nor
> can we rely on the frequency. Shouldn’t we be hiding these records from the
> OPAC as soon as they’re marked as “deleted”?
>
> I’ve opened a bug for this purpose:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537

I am in mild disfavor of this proposal, particularly as implemented in
current patch. Using a cronjob to delete records where Leader/05 is
set to 'd' is useful when the library has arranged their workflow such
that they *know* that Leader/05 = 'd' is being used consistently to
signify that a record is no longer wanted. However, for a library that
has not hitherto cared about the values in that position,
unconditionally suppressing the display of such records could come as
an unwelcome surprise.

That said, it is also a reasonable choice for a library to want to use
the Leader/05 as suppression criterion.  Consequently, I suggest
adding a configuration option.  For that matter, making it
configurable (say, by allowing the library to specify a set of query
additions for the purpose of filtering records from public display)
could result in a more generally useful mechanism.

> I admit that I have a special interest in this where I might
> be overlaying existing records using a mostly empty skeleton
>  record generated from an OAI-PMH identifier and a OAI-PMH
> deleted status (OAI-PMH doesn’t send metadata for deleted records).
>  I’d match the existing record in Koha using the identifier, and
> then set LDR05 to “d” in accordance with the OAI-PMH deleted
> status. Then, that record would disappear from the OPAC, so that
> end users don’t see this skeleton record.

I do not find this a compelling use case as stated.  If the goal is to
allow harvesting and overlay records from an OAI-PMH provider to also
delete bibs from a Koha database... coding so that the records are
*actually* deleted seems more direct.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Perldoc website

[Galen Charlton]

Hi,

On Tue, Dec 22, 2015 at 8:47 AM, Nicolas Legrand
<nicolas.legr...@bulac.fr> wrote:
> I'm a bit puzzled by the web perldoc, some changes are not effective
> on master.

It looks like that a while back an issue with the Git clone used for
generating the perldoc prevented updates from being fetched.  I've
corrected the issue and am regenerating the website now.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Link to the Current Stable Release is broken

[Galen Charlton]

Hi Stefano,

On Tue, Nov 3, 2015 at 4:13 AM, Stefano Bargioni <bargi...@pusc.it> wrote:
> At page http://koha-community.org/download-koha/, the link to the "Current 
> Stable Release (.tar.gz)" 
> <http://download.koha-community.org/koha-latest.tar.gz> is broken.
> Thx. Stefano

I checked, and it looks like somebody corrected the link earlier today.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] git commit messages

[Galen Charlton]

Hi,

On Wed, Sep 23, 2015 at 8:42 AM, Barton Chittenden
<bar...@bywatersolutions.com> wrote:
> 1) Convention (and possibly some koha programming standard) says that the
> bug number be included in the summary line of the commit message. Somewhere
> along the line, I assumed that this was an automated thing, so I left them
> off to avoid duplication :-/ (I'm in the process of fixing those). If we did
> want to automate this, where would we put it in the process?

I'm not sure that there's automation for putting the bug number in the
subject line of the commit, but there's certainly automation (e.g.,
the script that builds release notes) that depends on the bug number
being there -- (and consequently, the release notes can answer your
question about knowing in what versions a bugfix was applied, though I
grant that additional indexing might be nice).

I share Colin's preference for commit messages that describe the
change that the commit makes rather than the bug that the commit fixes
-- even more so when the commit message makes it clear how its effects
are visible to the user, and what, if anything, the user may need to
do about it.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] git commit messages

[Galen Charlton]

Hi,

On Wed, Sep 23, 2015 at 9:13 AM, Galen Charlton <g...@esilibrary.com> wrote:
> I'm not sure that there's automation for putting the bug number in the
> subject line of the commit, but there's certainly automation (e.g.,
> the script that builds release notes) that depends on the bug number
> being there -- (and consequently, the release notes can answer your
> question about knowing in what versions a bugfix was applied, though I
> grant that additional indexing might be nice).

And to that end, here's a little script I put together just now:

http://git.koha-community.org/gitweb/?p=contrib/global.git;a=blob;f=index-release-notes/extract_bugs_from_koha_release_notes;hb=HEAD

extract_bugs_from_koha_release_notes: grab bug numbers from Koha
release notes

This script extracts bug numbers referenced by Koha release notes and
outputs a two-column list of version numbers and bugs.

It should be run from within a clone of the Koha Git repository; usage is:

  extract_bugs_from_koha_release_notes > bug_index

TODO: this script doesn't currently recognize every way that
  bugs have gotten cited by release notes.

Cheers,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Cleaning up...

[Galen Charlton]

Hi,

On Fri, Sep 11, 2015 at 1:02 PM, Michael Hafen <michael.ha...@washk12.org>
wrote:

> I would suggest the cleanup_database.pl script in the cronjobs directory,
> except I've just looked at it and it doesn't touch the import_items or
> import_biblios tables.
>

Actually, it does, via the --import DAYS switch and cascading deletes.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] RFC: Reverting MARC batches with deleted records

[Galen Charlton]

Hi,

On Tue, Jun 23, 2015 at 12:39 PM, Kyle Hall kyle.m.h...@gmail.com wrote:
 The question becomes, is this the correct thing to do? If a record is
 deleted, shouldn't it stay deleted?

My gut reaction: it should stay deleted, as there was presumably some
other intentional action taken at some point to delete it.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] OPAC Validation error

[Galen Charlton]

Hi,

On Wed, Jun 10, 2015 at 8:24 AM, Owen Leonard oleon...@myacpl.org wrote:
 The last time I checked into it the answer is that you can't avoid the
 validation error. If I recall correctly, somewhere along the line the
 spec diverged from what others were implementing.

I can confirm that your understanding is correct.

 As long as it's providing us needed functionality and not breaking
 browsers, I say we ignore the error.

unAPI is still used by some applications, most notably Zotero.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] License question

[Galen Charlton]

Hi,

On Wed, Apr 29, 2015 at 8:36 PM, Mark Tompsett mtomp...@hotmail.com wrote:
 While looking at bug 5685, I noticed the newer version is only licensed
 under MIT. Is that license compatible with the GPL3 that Koha is?

From https://www.gnu.org/philosophy/license-list.html#Expat:

This is a lax, permissive non-copyleft free software license,
compatible with the GNU GPL. It is sometimes ambiguously referred to
as the MIT License.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] New coding guidelines on adding a syspref (INSERTIGNORE)

[Galen Charlton]

Hi,

On Tue, Apr 7, 2015 at 11:53 AM, Christopher Nighswonger
chris.nighswon...@gmail.com wrote:
 A long time ago, when I first opened this bug, I had hoped to code up a sub
 which would handle the check to see if the pref existed or not. The thought
 was to avoid the use of MySQLisms.

 I would think that this is a quick-and-easy, have-it-today fix, with the
 ultimate goal to be DB agnostic.

'INSERT IGNORE' is grep-able enough for future munging into a
DB-agnostic solution.

+1 to encouraging use of 'insert ignore' for now.

-1 to rejecting patches on account of it; QAers should instead supply
follow-ups if needed.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Git repository cleanup

[Galen Charlton]

Hi,

On Fri, Mar 27, 2015 at 11:55 AM, Tomas Cohen Arazi
tomasco...@gmail.com wrote:
 We have talked in the past about removing translation files from the git
 repo. For that to happen, we need to have a properly set translations
 repository, and a workflow modification (probably).

 Is there any work going on that direction?

Does a translations Git repository require any sort of special setup?
If not, creating the repo itself and giving the TM (and if needed for
the transition, RM  RMaints) push access would be trivial for me to
do.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Bugzilla and other sites outage

[Galen Charlton]

Hi,

On Sun, Mar 1, 2015 at 9:54 PM, Chris Cormack ch...@bigballofwax.co.nz wrote:
 Linode are rebooting all of their xen servers which will mean the VM that
 bugzilla and a bunch of other Koha sites and tools run on will disappear for
 a couple of hours.

 It will be rebooted at
 2015-03-07 6:00:00 PM UTC

 They have allocated a 2 hour window, but it should not be down that long.

For similar reasons, the IRC bot huginn will be down during the reboot
of the Linode hosting it:

2015-03-08 9:00:00 PM UTC

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Ambiguous column names

[Galen Charlton]

Hi,

On Wed, Nov 12, 2014 at 10:35 AM, Chris Cormack
ch...@bigballofwax.co.nz wrote:
 I think we don't need to make columns unique across the whole db just when
 selecting do select borrowers.timestamp as something.
 DBIx::Class helps us with this also

I agree with Chris.  In legacy code, doing a select * from a join on
multiple tables is should be discouraged, so using the addition of a
new column to locate cases of these to stamp out is preferable.  The
alternative of using a distinct column name has the problem of making
the writing of more general templates and classes more difficult.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Fwd: Questionaire regarding Patron Privacy and Security

[Galen Charlton]

Hi,

On Wed, Nov 12, 2014 at 3:34 PM, Brendan Gallagher
i...@bywatersolutions.com wrote:
 Can someone add info about LDAP to that list?  (someone with the correct
 technical terms that is ;) )

I've made an edit to the Etherpad to mention LDAP.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve?

[Galen Charlton]

Hi,

On Sun, Sep 7, 2014 at 9:59 PM, Indranil Das Gupta indr...@gmail.com wrote:
 I noticed that 003 and 005 tageditors do not actually have a popup to
 back them up. That unlike LDR (000), 007, 008 the tags 003 and 005 do
 not call any window.open function and their respective
 Clictag_number functions are blank.

 what is the purpose for having these tageditor links around for these two?

 curious to know :)

There's no particular reason for these to have tageditor links - as
you surmise, the only action of the plugins is to populate (empty) 003
and 005 fields with default values.

Consequently, the links could be removed, as they do nothing --
although if we do that, perhaps there should be some alternative
visual indication that something special happens if one clicks in
those fields.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve?

[Galen Charlton]

Hi,

On Mon, Sep 8, 2014 at 9:28 AM, Indranil Das Gupta indr...@gmail.com wrote:
 The max role I can see for 003 tageditor link is to provide a link to
 set MarcOrgCode syspref but then that is handled elsewhere. Perhaps a
 z39.50 server list alike link to this page -
 http://www.loc.gov/marc/authority/ecadorg.html and its provider links?

 For example, 
 http://www.loc.gov/marc/organizations/org-search.php?org_keyword=L2C2+Technologiessubmit=Search
 pulls up my data in the LOC Org code db. It could be wrapped into an
 impromptu API (as long as LOC does not change *their* db lookup
 process)

 Does something like that even make any sense? I'm just thinking aloud
 here (so I might be talking utter BS :P)

I think providing access to the whole LC organization code list would
be overkill unless you're using a Koha database as part of your
workflow to do contract cataloging for a bunch of libraries.

What might be useful for a consortium would be allowing more than one
value for MarcOrgCode.  In fact, that's already the topic of bug 10132
(MarcOrgCode would be useful on branch level). [1]

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

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] SIP2 AF field sent even if patron password is invalid

[Galen Charlton]

Hi,

On Tue, Jul 29, 2014 at 8:35 AM, Kyle Hall kyle.m.h...@gmail.com wrote:
 I have an interesting SIP2 implementation issue. When authenticating through
 SIP2, if a valid patron id is passed in, but an *invalid* password is passed
 in, Koha's SIP2 server send back the AF ( screen message ) field even though
 the credentials are invalid. If a patron owes any fees, the server will send
 back the amount owed in an AF field.

Sadly, it looks like the only provision that the SIP2 specification
makes for dealing with an invalid patron password is to set the CQ
field.  My reading of the spec is that the expected behavior regarding
other fields in the patron status and patron information responses is
undefined when an incorrect password is supplied.

 For instance, Overdrive will display this AF field even with an invalid
 password. Freegal does not ( but it may not display any AF field ). At least
 one SIP2 machine we tested against will also display the AF field when an
 invalid password is submitted.

 Is this a Koha issue, or a client side issue? The SIP2 protocol
 specification does not indicate that AF fields should be removed in the
 event of an invalid password. My guess is that some SIP2 server
 implementations may send back Invalid password messages which may be
 useful.

Possibly.  In any event, I think we should either not send an AF, or
send one that contains something like Invalid password if the patron
password is wrong.

That leaves open the question about what to do with other fields,
particularly in the patron information response.  My feeling is that
we should be conservative: if a patron password is sent via patron
status or patron information requests, and it's wrong, no information
about the patron should be returned.  There may need to be a
configuration option controlling this behavior.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] RFC: /svc/ API

[Galen Charlton]

Hi,

On Tue, Jul 22, 2014 at 5:11 PM, David Cook dc...@prosentient.com.au wrote:
 +1 to a versioned API. I don't think that I use it for anything at the
 moment, but I'm not 100% sure about all our apps. I think we might have a
 third-party one that uses it.

Also +1 to a versioned API.

 This script should probably also use PUT, but I have no idea if OCLC
 Connexion supports that.

I don't believe it matters as far as Connexion is concerned, as it
only talks to connexion_import_daemon.pl via a raw socket.

 Since there are an indeterminate number of third-party software systems
 using the existing API, I'd recommend versioning and using v2 to handle
 things more RESTfully.

MarcEdit is one program I know that uses the current API to inject
records into a Koha database.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] The schema of DBIx::Class is not up-to-date

[Galen Charlton]

Hi,

On Mon, Jul 7, 2014 at 7:10 AM, Yohann Dufour
yohann.duf...@biblibre.com wrote:
 I joined with this email the list of the differences between the DBIx::Class
 schema and the current database schema.

I believe that the difference in the generated schema classes can be
accounted for by the fact that you're using a newer version of
DBIx::Class::Schema::Loader.

When I was RM for 3.16, I was using DBIC::Schema::Loader version
v0.07025.  Yesterday Tomas and I did some checking of classes
generated using v0.07039.  Among other changes, the newer versions now
recognize set null as a FK action and default to restrict rather
than cascade if the action is not explicitly specified.

Those are both good changes, so I recommend that we require at least
version v0.07039 of DBIC::Schema::Loader.  Since that module is /not/
required for production use -- it's only needed for development --
requiring a hire version should not affect packaging signficantly.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Advise on DBIx

[Galen Charlton]

Hi

On Fri, Jul 4, 2014 at 11:16 AM, Tomas Cohen Arazi tomasco...@gmail.com wrote:
 it dies because No such relationship Deletedbiblioitem on Deletedbiblio.
 How shuold we cope with that situation? (I understand introducing a
 relationship would mean a lot of trouble as the tables are intended for
 deleted / not hard-linked data).

 Any ideas? Plain SQL?

Briefly, you can declare the relationship relationships in the DBIC
class without there having to be a corresponding FK in the underlying
SQL. That said, if this query is something that would be used
frequently, adding a FK relationship would be fine, or at least an
index.

 P.S. Happy independence day for those that apply :-D

Thanks!

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Extending MARC::Charset::Table ?

[Galen Charlton]

Hi,

On Wed, Jun 4, 2014 at 11:56 AM, Philippe Blouin 
philippe.blo...@inlibro.com wrote:

 We're using the MARC library for some migration, as usual, but we
 encountered some new issue with some arabic title: the key code 703
   0x02BF 703 MODIFIER LETTER LEFT HALF RING ʿ   is not part of the Table
 db, which cause the whole subfield to disappear and causing us headaches.



What is the source character encoding of the records?  If the records are
already in UTF-8, then it is not necessary to transcode them to MARC8, then
back to UTF8 for loading into Koha.  Adding the following line to whatever
code you're using to pre-process the records might help:

MARC::Charset-assume_unicode(1);

As an alternative, you could adjust change the records to use 0x02bb rather
than 0x02bf.  I'm assuming that the strings in question are transliterated
Arabic following the ALA-LC Arabic romanization.  If so, back in 1999, the
mapping of the ayn character was changed from 0x02bf to 0x02bb. [1]

[1] http://www.loc.gov/marc/marbi/2005/2005-05.html

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Convert circ tables to AJAX - possible for 3.16.1 ?

[Galen Charlton]

Hi,

On Thu, May 22, 2014 at 1:30 AM, Fridolin SOMERS
fridolin.som...@biblibre.com wrote:
 This enhancement looks like a little revolution in circulation,
 congratulations :D

 But it's big, and depends on Bug 11518, also enhancement.
 It will be not that easy to add in 3.14.x without generating bugs.

I agree.  -1 to backporting this to 3.14.x.

Backporting it to 3.16.x for inclusion to 3.16.1 stretches the rule of
no major enhancements in maintenance releases a bit, but does so in
the name of a worthy performance gain and and acknowledgment of the
consideration that there's only a month's span of time between the
release of 3.16.0 and 3.16.1.

Folks should consider bug 11703 impetus for upgrading to 3.16.1.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] RM transition note

[Galen Charlton]

Hi,

Just so folks know, Tomás and I discussed details of the RM handover
today.  The upshot is that after the release of 3.16.0 this Thursday,
I will go through the passed-QA queue and push patches to master and
3.16.x (as many of them will be wanted for 3.16.1 anyway).  Tomás will
begin pushing to master on Monday.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Reminder - development meeting tomorrow

[Galen Charlton]

Hi,

As a reminder, the next development meeting is scheduled for tomorrow,
21 May 2014, at 15:00 UTC and 22:00 UTC.  The agenda can be found at

http://wiki.koha-community.org/wiki/Development_IRC_meeting,_21_May_2014

Of particular note, I know that Tomás would like to discuss plans for
3.18 during the meeting.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Removal of the prog and CCSR themes in 3.18

[Galen Charlton]

Hi,

Just as a reminder, here's a section from the release notes for 3.14.0:

The 'prog' and 'CCSR' public catalog themes are deprecated as of the
release of Koha 3.14.0.  Existing Koha sites are encouraged to switch
to the Bootstrap theme as soon as convenient.  The 'prog' and 'CCSR'
OPAC themes are slated to be completely removed in the second major
release of Koha after 3.14.0, i.e., in the release currently
contemplated for November 2014.

That release currently contemplated for November 2014 is, of course, 3.18.0.

At this point, I'd like to request positive confirmation that folks
are still happy with that course of action; if we decide to change our
minds, we should do so prior to the release of 3.16.0.

Assuming that we don't change our minds, then as of now, there would
be no requirement that new patches update the prog theme.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Removal of the prog and CCSR themes in 3.18

[Galen Charlton]

Hi,

On Mon, May 12, 2014 at 7:55 AM, Galen Charlton g...@esilibrary.com wrote:
 Assuming that we don't change our minds, then as of now, there would
 be no requirement that new patches update the prog theme.

Also, I have opened bug 12233 for the removal of the themes.  Any
concerns about the mechanics of removing the deprecated themes should
probably go there.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Koha 3.16 beta available; string freeze belong

[Galen Charlton]

Hi,

The beta release of Koha 3.16 is available from
http://download.koha-community.org/.  For more details, please see
http://koha-community.org/koha-3-16-beta-released/.

As of now, a string freeze is in effect.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Find the patch!

[Galen Charlton]

Hi,

On Thu, May 1, 2014 at 1:51 AM, Jonathan Druart
jonathan.dru...@biblibre.com wrote:
 Sometime it is very difficult to find a patch, because you don't have
 enough information on what you are searching for. This tool will allow
 you to find Which patches modify this file [with which bug status],
 Which patches modify the GetBiblio routine, What is the bigger
 patch modifying this file, etc.

 The link: it is hosted by the Koha community :
 http://splitter.koha-community.org/

This is very, very neat.  Thanks for making this!

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] 3.16 release calendar

[Galen Charlton]

Hi,

On Tue, Apr 8, 2014 at 2:58 PM, Galen Charlton g...@esilibrary.com wrote:
 Wednesday, 30 April: beta release -- by the end of the day, I will
 clear the Passed QA queue and roll a beta release.  A soft string
 freeze will start upon release of the beta; at this point, translators
 can be confident that there won't be major string changes.

 Monday, 5 May: at the end of the day, a firm string freeze will
 beginning.  I will not call it a hard freeze, as security bugs and
 release blockers will trump string stability, but translators can
 expect that there will be no unnecessary changes.

I'm going to combine these two events.  In other words, I will release
the beta on Monday, and the firm string freeze will start then as
well.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Deprecating the Non-XSLT display on Detail and Search/List Results

[Galen Charlton]

Hi,

On Tue, Apr 29, 2014 at 12:40 AM, Magnus Enger mag...@enger.priv.no wrote:
 On 24 April 2014 05:12, David Cook dc...@prosentient.com.au wrote:
 What do people think about deprecating the non-XSLT display on detail and
 search/list results pages?

 +1.

 I'm not overly fond of XSLT as such, but reducing complexity is good.

I really want to hear from current users on this one.

I've sent out a tweet, but I suggest that somebody who is strongly in
favor of the deprecation also raise the question on the mailing list
-- in particular, whether there are folks who intentionally do not use
the XSLT option. If the consensus is to announce a deprecation, we may
as well do so upon the release of 3.16.0.

Of course, because of bug 10134, somebody who started with 3.12.0 or
later would have had to intentionally turn the XSLT option off.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Perl 5.18

[Galen Charlton]

Hi,

On Mon, Apr 28, 2014 at 7:43 AM, Tomas Cohen Arazi tomasco...@gmail.com wrote:
 The latest Ubuntu LTS release includes Perl 5.18. One of the main noticeable
 consequences of this is that some 5.10 features are now marked as
 experimental, and hence warnings appear everywhere.

 One example could be the use of '~~' (C4/Search.pm:536). These warnings can
 be avoided using the following pragma [1]:

 no if $] = 5.018, 'warnings', experimental::feature_name;

In my view, we should not use the pragma to hide the warning messages
-- we should remove use of the experimental constructs, including the
smartmatch operator.  There have already been a couple recent-ish
patches pushed [1] to remove uses of smartmatch.

This is because, as the link you included in your email states,
features that the Perl developers have marked as experimental are
subject to change, which could lead to surprises as future versions of
Perl get released.

I have opened a new bug [2] for removing the remaining uses of the
smartmatch operator, and I suggest that we add a new coding guideline
to this effect:

=== PERL19: The use of the Perl smartmatch operator is forbidden ===

The Perl smartmatch operator, including ~~ and given/when, has been
[http://perldoc.perl.org/5.18.0/perldelta.html#The-smartmatch-family-of-features-are-now-experimental
marked experimental] as of Perl 5.18.0.   Since the meaning of the
smartmatch operator is subject to change, and since using it will by
default add warnings to the error log, new code should not use it.

[1] Bugs 11468 and 11479
[2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12151

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Deprecating the Non-XSLT display on Detail and Search/List Results

[Galen Charlton]

Hi,

On Wed, Apr 23, 2014 at 8:12 PM, David Cook dc...@prosentient.com.au wrote:
 What do people think about deprecating the non-XSLT display on detail and
 search/list results pages?

0.  Here follows some thinking aloud:

One of the main advantages of the XSLT display templates is that they
have full access to the entire metadata record, and as a consequence
it's possible to put in complicated display logic without having to
write custom Perl code.  This mattered quite a bit at the time that
XSLT display system was introduced because HTML::Template::Pro lacked
good support for things like filters and template functions. Removing
the non-XSLT templates would also make it possible to remove a fair
amount of code for extracting data from MARC records, as that could be
left to the XSLT templates.

The big downside is that XSLT is not particularly user-friendly,
particularly if you want to make changes that go beyond tweaking a
couple labels.  The verbosity of XSLT's syntax also can get in the way
of developers wanting to make changes.  However, the importance of
that consideration depends on an answer to a question that I, for one,
don't have a good sense of: how many Koha libraries actually make
major changes to their OPAC record displays?

Nowadays, if I were asked to put together a fresh set of OPAC
templates for Koha, I would probably do it via Template Toolkit, but
organized differently: the search results and bib details code would
just pass along metadata (for now MARC::Record) and item objects to
the template, and there would be a site of helper functions available
for grabbing display values.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] git-bz update

[Galen Charlton]

Hi,

On Thu, Apr 24, 2014 at 5:30 AM, Owen Leonard oleon...@myacpl.org wrote:
 For those of us who had help installing git-bz in the first place,
 could you point us to instructions on how to update?

 http://wiki.koha-community.org/wiki/Git_bz_configuration

In particular, if your git-bz installation was done per those
instructions, an update would be done by changing to the directory
containing the clone of the git-bz repository, then running git
pull.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] March towards 3.16.0 #1

[Galen Charlton]

Hi,

I apologize for calling the dev meeting, but not being able to attend
it, but I have other unavoidable responsibilities today.  Here is a
quick update on 3.16.x:

- Feature freeze is still end of Monday, 28 April in the PDT time
zone.  Any patch that reaches passed QA by that point will be
considered for 3.16.0.  As I mentioned before, I'm granting leeway to
the new cataloging editor; I will also grant leeway to multiple
transport type enhancements, as there are a number of separate bug
reports, some of which have not yet gone through QA.

If there are things that you believe are close and worthy of leeway,
please reply to this thread.

- I will not be cutting an alpha today after all, but will still cut a
testing release on 30 April.  I may call it alpha or beta depending on
how stable it feels to me.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] git-bz update

[Galen Charlton]

Hi,

A couple days ago the latest security release was applied to Koha's
Bugzilla installation.  The security update included changes to login
handling to protect against CSRF attacks; this happened to break
git-bz's ability to upload patches and modify bug information.

I've pushed a patch that restores git-bz's ability to authenticate to
the 'fishsoup' branch of git://git.koha-community.org/git-bz.  If you
use git-bz, please update now.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] A note about the squeeze-dev repo

[Galen Charlton]

Hi,

On Mon, Apr 14, 2014 at 11:45 PM, Robin Sheat ro...@catalyst.net.nz wrote:
 I've just updated the koha in squeeze-dev to the latest master. However
 this won't update automatically, as 3.15.1 was in there previously (to
 force an update for the security update a few months back), and now the
 version is back to 3.15~git...

 Prior to the security update, the version was 3.15-1, but due to a more
 strict enforcement of the debian policy in recent versions, we have to
 drop the -1 part.

 So, if you are using packages from master (for testing purposes only, of
 course :), you'll want to do:

 sudo apt-get install koha-common=3.15~*

 to force the downgrade to the current version.

Thanks!

I'd like to tack on a semi-related (or possibly not at all related)
question.  Should we consider adopting a different set of code
names/suites for our APT repository?  For example:

testing
stable
oldstable
(maybe) reallyoldstable

or perhaps go by version number (modified as needed to confirm with
any toolchain expectations about the format of the suite name)?

3.16.x
3.14.x
etc.

Doing this would avoid any implications about which particular OS
releases a given package can work with.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Rename the repos?

[Galen Charlton]

Hi,

On Tue, Apr 15, 2014 at 10:28 AM, Mark Tompsett mtomp...@hotmail.com wrote:
 Keeping reallyoldstable: -0
 -- I'm kind of on the fence. It would be great to install an older stable
 version, but what is the point of hosting it, when someone could follow the
 instructions on the wiki
 (http://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way,
 for example) and roll their own earlier distribution from a git
 installation.

By that logic, why should we host an APT repository at all?

The answer, of course, is to make supported versions of Koha easy to
install.  I think we should be leery of directing folks at
instructions on how to roll their own packages unless they are doing
development for Koha or are an entity that is providing their own
support for an officially unsupported version of Koha.

This ties into a broader question of how many versions we want to
support.  My view is that we officially support a version, we should
provide packages for it (depending of course, on the availability of
people and tools to build them).

 Renaming by version number: -1
 -- I don't think having to do the modifications gives us added benefits,
 does it?

Well, there's a potentially a rather big benefit: not surprising
somebody who is tracking stable with a major version upgrade,
particularly since Koha falls in the category of usually being the
primary reason why a given server/VM exists

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] KohaDates filter questions...

[Galen Charlton]

Hi,

On Mon, Mar 31, 2014 at 7:49 AM, Mark Tompsett mtomp...@hotmail.com wrote:
 Glad to hear that either way works, but shouldn’t we aim for consistency?
 Should we not suggest a standard, even if we don’t enforce it?

-1 to making it a standard.  I have a personal preference for '='
over '=', but since TT accepts both forms, and I know of no
user-visible reasons to prefer one over the other, adding it to the
coding guidelines solely for the sake of consistency provides no real
benefit.

I note that with the possible exception of PERL1, none of the current
coding guidelines concern themselves solely with code styling
consistency.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Roles for 3.18; RMaints

[Galen Charlton]

Hi,

The current list of candidates for project roles can be found at

http://wiki.koha-community.org/wiki/Roles_for_3.18

We have candidates for all major project positions with the exception
of release maintainers for 3.12.x and 3.10.x.

I encourage folks to step up to run for RMaint, particularly for
3.12.x, but we should also discuss what the community support policy
for older releases should be.

For example, we could choose to support the most recent X stable
release branches, or we could decide that we want to support Y years
back, although given our release schedule either approach would work
out to the same outcome depending on how far back we want to go.

We should also consider what support means, particularly for the
older branches.  Several things that could be included in a definition
are:

- Having a release maintainer actively pushing bugfixes.  This is a
sine qua non, in my opinion.
- General community willingness to respond to questions and bug
reports with an answer that goes beyond please upgrade to the latest
stable branch
- Building release tarballs monthly (or maybe less frequently for
older branches)
- Building Debian packages
- Willingness to do security releases

Related, the next development meeting is scheduled for Wednesday, 23
April 2014, as a two part meeting at 15:00 UTC and 22:00 UTC.  Voting
on the project roles will be on the agenda for that meeting.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] 3.16 release calendar

[Galen Charlton]

Hi,

I'm setting the following dates for the next steps in the Koha release
cycle.  Note that date for deadlines should be interpreted to mean
that they finish at 23:59 in my time zone, which is presently
UTC-08:00.

Wednesday, 23 April: alpha release -- I will clear the passed QA queue
and roll a tarball.

Monday, 28 April: feature freeze -- any new feature or enhancement bug
must have reached Passed QA by the end of that day to be considered
for inclusion.  Note that I may grant the new cataloging editor up to
two days of leeway on this deadline.

Wednesday, 30 April: beta release -- by the end of the day, I will
clear the Passed QA queue and roll a beta release.  A soft string
freeze will start upon release of the beta; at this point, translators
can be confident that there won't be major string changes.

Monday, 5 May: at the end of the day, a firm string freeze will
beginning.  I will not call it a hard freeze, as security bugs and
release blockers will trump string stability, but translators can
expect that there will be no unnecessary changes.

Monday, 19 May: I will cut the release candidate

Thursday: 22 May: General release.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Problem on git server

[Galen Charlton]

Hi,

On Mon, Mar 31, 2014 at 2:18 AM, Zeno Tajoli z.taj...@cineca.it wrote:
 there are problems on git server ?
 My request of 'git pull' doesn't work.
 I receive:
 fatal: read error: Connection reset by peer

It works for me at the moment.  Please advise if it's still not working for you.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Update database error on Koha install

[Galen Charlton]

Hi,

On Tue, Mar 25, 2014 at 8:38 AM, Scott Kushner
skush...@mplmain.mtpl.org wrote:
 Does anyone know how to get around this? It seems that I'm stuck in a loop
 with the installer and cannot get out!

 Any help would be appreciated.

It looks like some manual SQL would be called for, following the steps
in the relevant database schema update.  Specifically, since it looks
like that the borrowernumber column is already present, probably from
a previous run, you should try:

[1] UPDATE patronimage LEFT JOIN borrowers USING ( cardnumber ) SET
patronimage.borrowernumber = borrowers.borrowernumber;

[2] ALTER TABLE patronimage DROP FOREIGN KEY patronimage_fk1;

It's possible that this one may fail if no such foreign key with that
name exists.  If so, that's fine, you can continue on:

[3] ALTER TABLE patronimage DROP PRIMARY KEY, ADD PRIMARY KEY( borrowernumber );

[4] ALTER TABLE patronimage DROP cardnumber;

[5] ALTER TABLE patronimage ADD FOREIGN KEY ( borrowernumber )
REFERENCES borrowers ( borrowernumber ) ON DELETE CASCADE ON UPDATE
CASCADE;

If you get this far, the final step is to tell Koha that you've
successfully installed that DB revision:

UPDATE systempreferences SET value = '3.1300030' WHERE variable = 'Version';

After that, you should be able to proceed with the rest of the schema upgrade.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Proposed to delete table aqorderdelivery (bug 11928)

[Galen Charlton]

Hi,

On Wed, Mar 12, 2014 at 6:00 AM, Zeno Tajoli z.taj...@cineca.it wrote:
 here, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11928,
 I propose to delete Mysql table aqorderdelivery

+1.  I've signed off on Mark's patch to remove it.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Calculating priority for new hold requests

[Galen Charlton]

Hi,

An issue that's bugged me for a while is the fact that AddReserve()
relies on the caller to set the priority of the request.  That
historically has meant that there are several different places in the
code where the priority is calculated, and the code duplication means
that there's a risk of it getting calculated slightly differently.
Furthermore, there's the potential for a race condition if the patron
or staff member takes a while to actually submit the hold request.

The patch for bug 8918 offers the potential start of an improvement
for this situation by defining a new central routine to calculate the
priority, although at present CalculatePriority() is used in only one
place.  However, I'd like to suggest that rather than simply expanding
the use of CalculatePriority(), that it instead by called by
AddReserve() and that the $priority parameter of AddReserve() be
removed.  This would have the effect of pushing each new request to
the end of the line (with variations for future holds and item-level
requests).

As near as I can tell, all of the places that call AddReserves()
alreay implement this policy (including serials/routing-preview.pl,
although indirectly).  However, I would appreciate a check of that
assumption.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Calculating priority for new hold requests

[Galen Charlton]

Hi,

On Mon, Mar 10, 2014 at 10:29 AM, Galen Charlton g...@esilibrary.com wrote:
 The patch for bug 8918 offers the potential start of an improvement
 for this situation by defining a new central routine to calculate the
 priority, although at present CalculatePriority() is used in only one
 place.  However, I'd like to suggest that rather than simply expanding
 the use of CalculatePriority(), that it instead by called by
 AddReserve() and that the $priority parameter of AddReserve() be
 removed.  This would have the effect of pushing each new request to
 the end of the line (with variations for future holds and item-level
 requests).

By the way, there is already a relevant bug open: 11640.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] A volunteer for 3.12.x during April?

[Galen Charlton]

Hi,

On Mon, Mar 10, 2014 at 5:22 PM, Chris Cormack chr...@catalyst.net.nz wrote:
 * Tomas Cohen Arazi (tomasco...@gmail.com) wrote:
Hi, I'll be offline during April (trip) and would need someone to
volunteer for the 3.12.x RMaint position.

 I can take over for April, if that is ok with others.

+1 and thanks, Chris.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] update22_to_30.pl throwing MySQL syntax error while creating `labels` table

[Galen Charlton]

Hi,

On Fri, Mar 7, 2014 at 7:39 AM, Indranil Das Gupta indr...@gmail.com wrote:
 While migrating an ancient but very much in production 2.2.5 db to
 3.14, ran into a small bug in the update script. I worked around it by
 changing 'timestamp(14)` to simply 'timestamp'

 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11908

 Do I go ahead and write a patch? Or simply ignore it?

Go ahead and write a patch if you feel inclined -- it would fix a
problem, and anything that makes it easier for folks still running
Koha 2 to upgrade is a good thing.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Reminder: General IRC meeting is 5 March 2014 at 19:00 UTC

[Galen Charlton]

Hi,

On Wed, Mar 5, 2014 at 5:32 AM, Owen Leonard oleon...@myacpl.org wrote:
 This is a reminder that the next general IRC meeting is 5 March 2014
 at 19:00 UTC (in about 4 hours as of this writing)

The minutes can be found at:

http://meetings.koha-community.org/2014/koha_general_meeting__5_march_2014.2014-03-05-19.05.html

The logs can be found at:

http://meetings.koha-community.org/2014/koha_general_meeting__5_march_2014.2014-03-05-19.05.log.html

I would like to direct folks' attention in particular to our decision
to schedule the next meeting to occur in two parts on 9 April 2014:
once at 15:00 UTC, and again at 21:00 UTC.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] File sizes

[Galen Charlton]

Hi,

On Fri, Feb 28, 2014 at 10:52 AM, Paul A pau...@navalmarinearchive.com wrote:
[snip]
 -rw-rw 1 mysql mysql 1117782016 Feb 28 18:43 ibdata1
 [log files identical]

 Two questions if I may.  First, are my numbers typical?

Hard to say without knowing how many bibs you have.

Regardless, if you're not using the innodb_file_per_table option, you
should be, as it allows one to recover space from individual tables
without having to reload the entire database.

 Second, has MariaDB been shelved permanently?

Far from it.  At present, I've seen no issues using MariaDB 5.5 as a
drop-in replacement for MySQL, either on my personal development boxes
or in production use.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] File sizes

[Galen Charlton]

Hi,

On Fri, Feb 28, 2014 at 12:37 PM, Michael Hafen
michael.ha...@washk12.org wrote:
[snip]
 -rw-rw 1 mysql mysql 1551892480 Feb 28 12:53 import_records.ibd
[snip]
 -rw-rw 1 mysql mysql  490733568 Feb 28 13:30 zebraqueue.ibd

One thing to note is that if you use cleanup_database.pl to do things
like trim the zebraqueue table or purge old staged import records,
following up with an occasional 'optimize table' will recover the disk
space -- particularly if you've never run cleanup_database.pl at all.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] File sizes

[Galen Charlton]

Hi,

On Fri, Feb 28, 2014 at 2:54 PM, Paul A pau...@navalmarinearchive.com wrote:
 At 12:59 PM 2/28/2014 -0800, Galen Charlton wrote:

 We've found that it's the 'sessions' that accumulate. We cron it every
 morning at 3am, but I just ran it manually now (13.5 hours later) and get:

 whoever@nelson:/usr/share/koha$ ./bin/cronjobs/cleanup_database.pl
 --sessions -v
 Session purge triggered.
 55203 entries will be deleted.
 Done with session purge.
 [This is maybe [???] due to some bots that don't respect the robots.txt
 (baidu? I'm getting close to blocking them at router level)]

I'm personally fond of using the option to store sessions in
memcached.  But this is also an example of where innodb_file_per_table
is nice, being able to run an 'optimize table session' would let you
reclaim disk space.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Feedback requested

[Galen Charlton]

Hi,

On Wed, Feb 26, 2014 at 9:26 AM, Mark Tompsett mtomp...@hotmail.com wrote:
 I was wondering if other developers would care to comment on recommended
 disk space sizes for a git install on Bug 11830. Thank you!

More of a meta-level concern: I don't think INSTALL.${just_one_os} is
the right place to be expressing system specifications.  The wiki
would be a better place for that -- even better, although it would
depend on finding somebody willing to maintain it, would be a page on
the main website that gathers together recommend specs.

Further commentary on the disagreement about the numbers I will leave
in the bug.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] DataTables - using class names in aTargets

[Galen Charlton]

Hi,

There have been a fair number of bugs filed for fixing table sorting
as columns get added to or removed from tables.  At root, they stem
from our current habit of referring to columns by numeric position in
aoColumns and aoColumnDefs/aTargets, e.g.,

{ aTargets: [ 1, 2 ], sType: natural  }

and

aoColumns: [
{ sType: title-string },{ sType: html },null,{
sType: title-string },null,null,null,null,null,null[% IF (
exports_enabled ) %],null[% END %]
],

However, the documentation for DataTables says that aTargets doesn't
have to be just an array of integers; it can also be a string - class
name will be matched on the TH for the column.

To reduce the risk of silly columns-sorting bugs, I suggest that we
adopt a practice of using descriptive CSS class names for table
headers and using the class names in aoColumnsDefs/aTarget
specifications, and dropping the use of aoColumns.

Thoughts?

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Development meeting - save the date

[Galen Charlton]

Hi,

I am calling a development meeting for Tuesday, 25 February 2014, to
be held in the #koha IRC channel.  All are welcome, but the focus will
be on development topics.  Tentatively, I would like to discuss the
following topics:

- DBIx::Class and guidelines for its use in Koha
- Search engine work, including enhancements to usage of Zebra and
Elastic Search
- Pending large enhancements for 3.16

The agenda is being kept intentionally short to permit an in-depth
discussion of each item, but if there is a topic that you want to be
covered and which requires the participation of most or all of the
active developers, please let me know.

To permit everybody to participate, I propose that we effectively meet
/twice/ that day.

15:00 UTC+0 
(http://www.timeanddate.com/worldclock/fixedtime.html?msg=xxxiso=20140225T15)

and

21:00 UTC+0 
(http://www.timeanddate.com/worldclock/fixedtime.html?msg=xxxiso=20140225T21)

I will be attending both parts, of course, and will try to act as a
bridge between the two sessions.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] FYI: CVE numbers for recent security update

[Galen Charlton]

Hi,

I requested CVE numbers for the issues fixed in the security releases;
here's what was assigned:

CVE-2014-1922: absolute path traversal issue in tools/pdfViewer.pl
CVE-2014-1923: directory traversal issues in edithelp.pl and member-picupload.pl
CVE-2014-1924: MARC framework import/export did not require authentication
CVE-2014-1925: MARC framework import/export could be used to perform
unexpected SQL commands

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] IMPORTANT: Koha security release

[Galen Charlton]

[apologies for the multi-post, but if there are any folks who are
subscribed to koha-devel but not the general list, they need to see
this too]

The Koha community is releasing a security update for all supported
and recent unsupported versions of Koha. The security update is
available in the following new releases being made today:

* 3.14.3
* 3.12.10
* 3.10.13
* 3.8.23

The following security bugs are fixed by this update:

* Bug 11660: tools/pdfViewer.pl could be used to read arbitrary files
on the server
* Bug 11661: the staff interface help editor could be used to modify
or create arbitrary files on the server with the privileges of the
Apache user
* Bug 11662: member-picupload.pl could be used to write to arbitrary
files on the server with the privileges of the Apache user
* Bug 11666: the MARC framework import/export function did not require
authentication, and could be used to perform unexpected SQL commands

The fix for bug 11666 removes SQL as a supported format for importing
or exporting MARC frameworks.

We recommend that you upgrade immediately to get the fixes for these
security issues. However, if you are not able to perform the upgrade
right away, you can mitigate against the issues by performing the
following actions:

* deleting the pdfViewer.pl script
* deleting the member-picupload.pl script
* making edithelp.pl not be executable, e.g., by doing

  chmod a-x edithelp.pl

* making import_export_framework.pl not be executable, which will
disable the MARC framework import and export functionality

Our thanks to John Lightsey for finding and reporting the issues.

The 3.14.3 and 3.10.13 releases also contain unrelated bugfixes which
are described in their release notes.

Please note that if you installed from a tarball, you may need to
manually delete pdfViewer.pl and member-picupload.pl, even after you
upgrade.

Users of the Debian packages for 3.12.x and 3.14.x (and master) can
get the latest release by running apt-get update followed by apt-get
upgrade.

Tarballs are also available and can be downloaded from
http://download.koha-community.org.

If you are not running a version of Koha that has has a release
maintainer (currently 3.8.x, 3.10.x, 3.12.x, and 3.14.x), we strongly
urge you to upgrade to a supported version.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Reporting security bugs

[Galen Charlton]

Hi,

There is now a mechanism in place for reporting security bugs via
Bugzilla.  If you look at the footer, you should now see a 'Report
security bug' link.  This allows someone who has a Bugzilla account to
enter a bug in a new BZ product called 'Koha security'.

Bugs reported in this fashion are visible only to the reporter and to
members of a Koha security group currently consisting of the following
individuals:

 Bernardo Gonzalez Kriegel
 Chris Cormack
 Frère Sébastien Marie
 Fridolin SOMERS
 Galen Charlton
 Ian Walls
 Jared Camins-Esakov
 Jonathan Druart
 Katrin Fischer
 Kyle M Hall
 M. de Rooy
 MJ Ray (software.coop)
 Paul Poulain
 Robin Sheat
 Tomás Cohen Arazi

The idea is that members of the security group would be responsible
for evaluating the bugs, fixing them (and drawing in outside help if
needed), and releasing the fixes.  Once a fix is released, the
relevant bug(s) would be sanitized to remove mention of direct
exploits, then have their products changed to 'Koha' so that they
would be visible to all.

This is not set in stone, so I invite discussion of the security
policy. I also invite anybody who may have been sitting on security
bugs for lack of a means to report them securely to go ahead and use
BZ.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] meetings.koha-community.org site - link for 2014 meetings

[Galen Charlton]

Hi,

On Sun, Feb 2, 2014 at 1:24 AM, David Nind david.n...@gmail.com wrote:
 For http://meetings.koha-community.org/ there is no link on the main page or
 sub pages for the 2014 meetings.

I've added this.  Thanks for pointing this out.

 I couldn't find the details of who looks after this site on
 http://wiki.koha-community.org/wiki/Website_Administration

I've updated the wiki page.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Modules only on CPAN

[Galen Charlton]

Hi,

On Fri, Jan 31, 2014 at 1:05 AM, Martin Renvoize 
martin.renvo...@ptfs-europe.com wrote:

 If search results are all we are paginating server-side then shouldn't we
 really be focusing on search relevancy and limiting results down such that
 we don't really need to paginate at all?  (I'm kinda hoping that the
 elastic search work will go a long way to solving this dilemma...) I would
 put money on analytic's showing that most users give up after page two or
 three of the results at the latest.


I would not be surprised that there is evidence that most users, most of
the time, don't go past the first page or so of search results.

However, most is not everybody and is not every time, and is
decidedly not the librarians who are among Koha's users, and who have
legitimate search needs that are different from most patrons.  I do not
have confidence that any search engine that exists now is going to solve
the relevance problem perfectly until the advent of both real strong AI and
telepathy. (And we might discover we have ... other problems should a
strong AI arise ;) ).  I also don't foresee Google dropping search result
paging any time soon.

That's not to say that we shouldn't look at all avenues of improving search
result sorting, but I do suggest that a separate thread would be better for
discussing that.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Modules only on CPAN

[Galen Charlton]

Hi,

On Thu, Jan 30, 2014 at 7:52 AM, Owen Leonard oleon...@myacpl.org wrote:
 It is only used in opac/search.pl.

 I think pagination should not be done into perl. We use JQuery Datatables
 for that.

 Perhaps, assuming you mean AJAX-loaded pagination, since bibliographic
 search results can potentially have hundreds of thousands of results.
 However, the OPAC ought to have a non-JavaScript fallback.

Agreed, there is a place for server-calculated pagination.  I also
agree that Data::Pagination needs to be replaced.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] [Koha] Problems with frameworks

[Galen Charlton]

Hi,

On Thu, Jan 23, 2014 at 4:40 AM, Marcel de Rooy
m.de.r...@rijksmuseum.nl wrote:
 It seems to me that 541$e should not map to an item field (in the first 
 place). I checked my data, i do not have it mapped to a koha field.
 I have 952$i mapped to stocknumber (although we do not use it).

Agreed -- Koha assumes that every item field that gets mapped to/from
a subfield uses the same field tag.  It does not support using
multiple fields to represent items, and it would be awkward to
implement such a thing, considering that more than one item can be
attached to a bib.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Automatic renewal feature

[Galen Charlton]

Hi,

On Fri, Jan 17, 2014 at 7:16 AM, Holger Meissner
holger.meiss...@hs-gesundheit.de wrote:
 Eric Bégin wrote:
 Instead of implementing this in the issuing rules, I think we could add
 an Automatic renewal checkbox on the checkout page and adding
 this value in the issues table.

 I think my library needs this as part of the issuing rules, because
 we have certain patron categories that generally are to be automatically
 renewed. But other libraries might want to use the feature for individual
 patrons or even single checkouts. So it might be best to implement
 it both in the issung rules and on the checkout page?

Yes.  Here is how I suggest doing it:

- add an auto_renew flag to both issuingrules and issues
- when a loan is made, issues.auto_renew is set to the value of
issuingrules.auto_renew from the loan rule that was applied.
- the cronjob checks issues.auto_renew -- in other words, it doesn't
go back and check issuingrules again, it just goes by the value set on
the loan itself.

That way, the door would be open for Eric's checkbox while fulfilling
your need for the behavior to be controlled by circ policy.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] Suggestion for OPAC theme bug fix patches

[Galen Charlton]

Hi,

If you're writing a patch that fixes a bug with an OPAC template file,
you'll need to at least touch the Bootstrap theme, but you may also
want to touch the prog theme if you think the fix should be backported
back to 3.12.x or earlier.

Here's my suggestion: if you do that, please put your prog and
Bootstrap template changes in separate patches.  That way, it will be
easier for the RMaints for 3.12.x, 3.10.x, and 3.8.x to cherry-pick
the appropriate patches without having to manually disentangle out the
Bootstrap theme bits that don't apply.  This, in turn, will likely
increase the chance of your bugfix being backported.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] [Koha] Collection usage report: issues field in items table

[Galen Charlton]

Hi Chad,

On Fri, Jan 10, 2014 at 3:02 PM, Chad Roseburg croseb...@ncrl.org wrote:
 I'm trying to assess the usage of a particular collection and am wondering
 if the 'issues' field in the items table represents all issues: Ie., both
 from the old_issues and issues tables.

Yes -- items.issues gets incremented every time an item is checked
out, so if all you need is a count, you don't need to include either
the issues or old_issues tables in your query.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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] RFC: make OPAC XSLT be shared by all themes

[Galen Charlton]

Hi,

While working on bug 11310 to sync up bootstrap/en/xslt with
prog/en/xslt, it occurred to me that at present there's no reason why
the OPAC XSLT couldn't be shared by all themes.  In particular, CCSR
falls back to prog's XSLT, and to date there has been no sign of a
need for XSLT specific to the Bootstrap theme.

Consequently, I propose to move koha-tmpl/opac-tmpl/prog/en/xslt to
(say) koha-tmpl/opac-tmpl/xslt/en, with appropriate adjustments to the
translation scripts so that koha-tmpl/opac-tmpl/xslt/fr-FR, etc., can
be generated.

I would appreciate feedback on the proposal -- in particular, I'd like
to know if anybody knows of a concrete reason for  needing
theme-specific results and details stylesheets.

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

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Koha 3.12.x and VIAF

[Galen Charlton]

Hi,

On Wed, Dec 25, 2013 at 11:25 PM, Partha Mukhopadhyay psm...@india.com wrote:
 Thanks Stefano Bargioni. Excellent solution. It s as good as your smart
 script to use Lined Open Data (LOD) in authority control. I tested it on
 Koha 3.12.X as well in Koha 3.14. In both the cases it rocked. One question
 (asking too many??)-  in Koha 3.14 one utility (infact a long awaited
 utility) added to search authority records from Z 39.50 sever. Do you know
 any specific name authority server details? irspy.com is giving list for
 bibliographic data server only.

The US Library of Congress makes its name and subject authority
records available via Z39.50.  Access information can be found at:

http://www.loc.gov/z3950/lcserver.html#addr

The National Library of Australia does as well, although one might
have to purchase a subscription for full access.  Nonetheless,
connection information can be found at:

http://www.nla.gov.au/librariesaustralia/services/search/z3950/

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Modules only on CPAN

[Galen Charlton]

Hi,

On Fri, Dec 20, 2013 at 3:40 AM, Zeno Tajoli z.taj...@cineca.it wrote:
 In my opinion Data::Pagination and Archive::Extract could be packages
 in http://debian.koha-community.org, the others no (because are only for
 developer).

There's a problem with packaging Data::Pagination -- there is no
copyright information documented with the module, meaning that a
package could not be accepted into Debian proper.  Attempts [1] by
Robin and Tomás to get the maintainer to supply copyright and license
statements have met with silence.

That isn't a technical bar to building a .deb and putting it up on
Koha's APT repo, but we should avoid doing so unless there is no other
choice.  However, there are other pagination modules available,
including at least one (Data::Page) that is already packaged for
Debian.  There's only one script that uses Data::Pagination (and a
module that imports it but doesn't use it), so making a switch
shouldn't be very time consuming.

It looks like Archive::Extract has been packaged for Jessie, so
presumably making a backport to host on our APT repo would be
feasible.

[1] https://rt.cpan.org/Public/Bug/Display.html?id=8

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Architectural goals for 3.16

[Galen Charlton]

Hi

On Fri, Dec 20, 2013 at 1:21 AM, Jonathan Druart
jonathan.dru...@biblibre.com wrote:
 2013/12/19 Galen Charlton g...@esilibrary.com:
 I have already created an account for sandboxes' SO : sandbo...@biblibre.com.
 By signing off, the form asks for a name and an email address. These 2
 information are used to fill the Signed-off-by line in the commit
 message.
 It is not possible to switch the bz status to signed off by using the
 sandbox interface: the script has to log in bugzilla for that and I
 don't want to ask for a password in the sandbox interface.

Quite right -- it had slipped my mind momentarily that the dashboard's
count of signoffs goes by Bugzilla status changes, not the line in the
commit message.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Architectural goals for 3.16

[Galen Charlton]

Hi,

On Thu, Dec 19, 2013 at 8:17 AM, Paul Poulain paul.poul...@biblibre.com wrote:
 Le 18/12/2013 23:31, Galen Charlton a écrit :
 Paul Poulain- 63
 I don't endorse those 63: most of them (if not all) were in fact
 sandboxes signoff, because I use my account to send signoff from the
 sandboxes. Maybe we should/could create a generic sandbox signoff
 account ?

I think that's a good idea.  Another idea (if it doesn't do it
already) would be to have the sandbox ask the user to supply their
name and email address so that they can be individually credited with
the signoff if they want.

 One for one is a minimum, I feel -- there are several organizations
 that average two or more patches reviewed for each one they author.
 [2]
 I'm a little bit uncomfortable with those numbers because they can't
 show the time we dedicate to rebasing patches. When you submit an
 enhancement that is not pushed quickly, rebasing 4 or 5 times is common.
 And that's a part of the quality process. And we try to have a very good
 reactivity on this matter.
 But those number can also convince me to ask someone from my staff to
 get involved (on a regular basis).

Great!  I hope they do so.

 And if I were playful[*], I would bounce[*] on the fact that you highly
 value the work we're doing: thank you for that. I'm sure then, as you
 value it so high, that you'll try to find a way to conserve (or even
 improve) our enthusiasm, right ? ;-)

 [*] strictly no negative meaning here, I hope google translate didn't
 lied to me with these words...

Google Translate didn't lie to you.  And thank you.

 Users who have customized their Zebra index definitions will have more
 work to do during an upgrade, however.
 OTOH, those who are able to customize their zebra index definitions also
 have the skills to double check their upgrade ;-)

One can only hope. :)

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org 
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Architectural goals for 3.16

[Galen Charlton]

Hi,

On Wed, Dec 18, 2013 at 8:38 AM, Paul Poulain paul.poul...@biblibre.com wrote:
 Le 10/12/2013 01:59, Galen Charlton a écrit :
 I'd like to see as many of the 70 improvements or new features already
 submitted by BibLibre (plus more coming) being signed-off, QAed and
 pushed (Sorry if I appear a little bit rude)

 Same thing for the 120 improvements or new features not submitted by
 BibLibre and that are in the same status.

I'll be direct: it is not enough to submit a patch, then expect it to
be reviewed quickly.  Eventually most things will get looked at by
other developers in the community.

Eventually is a rather imprecise time period, of course, and I
appreciate how awkward it is.  For good or ill, to my knowledge
there's nobody who is time is being sponsored specifically to do patch
review.  We are quite fortunate that there are folks who are doing it
anyway.  I would like to publicly call out and thank the folks who
have done 50 or more initial patch signoffs according to Bugzilla this
year:

Kyle M Hall- 262
Bernardo Gonzalez Kriegel- 192
Chris Cormack- 182
Owen Leonard- 177
Jonathan Druart- 112
M. de Rooy- 112
Srdjan Jankovic- 87
Katrin Fischer- 68
Paul Poulain- 63
Liz Rea- 50

I would also like to thank the folks who have reviewed any patches at
all, too -- for the complete list so far, scroll to the bottom of the
page at http://dashboard.koha-community.org/.

Nonetheless, there needs to be more people signing off on things, period.

However, I submit the following thesis: organizations -- and I use the
word organization intentionally -- who author a lot of patches
should also be doing a lot of patch review.  More to the point, that
patch review should be distributed, not just depend on the efforts of
a subset of the developer employees..

That last sentence is yes, directed at BibLibre, but not just at
BibLibre. There are several organizations active in Koha development
who have more than one person authoring patches on a regular basis.
Not all of them are reviewing patches at a proportional rate.

Thus, my challenge to everybody, but in particular to multi-developer
organizations: consider implementing a practice of *at least* one for
one.  In other words, for each patch you submit, review another
developer's patch.  Review doesn't mean automatic signoff -- it's
valid feedback to mark a patch as failed QA so long as you explain
why.  If an organization has got an employee who is active on the QA
team, their QA work counts too, of course -- but that shouldn't put
the other developers of that organization off the hook for doing their
share of patch review.

One for one is a minimum, I feel -- there are several organizations
that average two or more patches reviewed for each one they author.
[2]

One thing I will add  -- if one looks at the commits pushed to the
master branch, starting with the beginning of the 3.2 development
cycle through the release of 3.14.0, the release manager who has
pushed the most patches authored by BibLibre is... me.  This isn't
actually a terribly interesting fact, as a lot of factors contribute
to the ebb and flow of which patches get pushed when, but I hope you
will take this as indication that I highly value the work that
BibLibre has done and continues to do.

  [1] Deprecation of the GRS-1 mode for Zebra.
 +1

  Obstacles: the default UNIMARC indexing rules for the DOM filter need
  more testing.  There is also an ongoing discussion about the desired
  semantics for the Any index, which at present behaves differently with
  the current DOM indexing rules as compared with GRS-1.
 And BibLibre should be a leader here, I apologize because we aren't

Great -- I look forward to BibLibre taking a more active role on this front.

  Upgrade considerations: in order to truly deprecate the GRS-1 filter, at
  some point there will have to be a forced reindexing upon upgrade.
 Note that when upgrading from 3.6 to 3.8 (iirc), one also had to run a
 separate script to remove items from marcxml, so having a complex
 upgrade is uncommon but not never happened

I agree -- a forced reindexing is by no means the end of the world in
the simplest case: it just adds time to the upgrade process, but that
can be planned for.

Users who have customized their Zebra index definitions will have more
work to do during an upgrade, however.

  [2] Use DBIx::Class to deploy the database schema for new installations.
 No opinion, because I'm not sure I see all the consequences.

Using DBIx::Class to deploy the schema would facilitate PostgreSQL
support.  Of more immediate interest, however, use of
DBIx::Class::Schema::Versioned or the like to manage database updates
would provide an alternative that doesn't rely on bespoke code.

The primary obstacle to use of DBIC for deploying the schema is that
DBIC doesn't inherently know anything about how to create indexes or
which indexes to create.  It also doesn't know anything about which
MySQL storage engine to use.

Fortunately, DBIC does provide