Re: [Koha-devel] Critical error on Koha website

[Liz Rea]

Hi friends,

This was related to an update to Wordpress and the theme we use. Have
sorted out those issues and things are seeming better now, if you'd please
test!

Cheers,
Liz

On Thu, Sep 29, 2022 at 2:51 PM Michael Kuhn  wrote:

> Hi
>
> When I'm trying to preview or release the current Koha newsletter I'm
> getting the following message:
>
> There has been a critical error on this website.
>
> I'm also getting this message when I try to access older newsletters,
> for example
>
> * https://koha-community.org/koha-community-newsletter-april-2022/
> * https://koha-community.org/koha-community-newsletter-august-2022/
>
> Can someone with the necessary rights and knowledge please remove this
> problem?
>
> 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
> 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/
>
___
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/

[Koha-devel] Fwd: Repack git repo

[Liz Rea]

Hi all,

As the release is now done, yesterday ~3pm Central Standard Time I ran a
repack on the Koha repo. The repo is now 1.03G in size, down from 4.6G.

There is more work to be done on that server - namely it's got a old and
busted (and cantankerous!) OS, and thusly an old and busted (and
cantankerous!) git version. It will need an upgrade at least, and it may
end up being a server move.

I don't have a timeline for any of that, but will aim to make it as
unimpactful as I can when it happens, and will let everybody know closer to
the time.

Cheers,
Liz



On Tue, Apr 28, 2020 at 4:57 PM Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:

> The wiki page is outdated, I will try and update it soon. I managed to
> get rid of po files and l kept the history and tags (using BFG instead
> of git filter-branch).
>
> Le mar. 28 avr. 2020 à 20:02, Mark Tompsett  a
> écrit :
> >
> > Greetings,
> >
> > I checked out the wiki page. Thank you for typing that up, Jonathan.
> >
> > I vote for keeping tags (hey GB to MB -- we can keep tags), and I really
> like:
> >
> https://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking#Howto_use_Koha_main_repo_with_localization_repo
> >
> > It's still pretty clean in terms of getting all of Koha.
> >
> > GPML,
> > Mark Tompsett
> > ___
> > 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/
> ___
> 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/
>
___
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] Repack git repo

[Liz Rea]

Ok, what time of day in UTC do you like for this?

On Tue, Apr 28, 2020 at 3:19 AM Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:

> Hi devs,
>
> Some of you may know, we got an issue with our Koha gitlab repo, it
> was not syncing because of too big (no detail here, but that did not
> really make sense anyway). It seems that it is syncing now but we
> removed all the branches that are not protected (so only master)
>
> I had a new try at splitting our repo, removing the po files from the
> core repo (
> https://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking).
> It's not a trivial process as it requires several changes, but I
> noticed that:
>
> After a git clone: `git count-objects -vH` returns 3.67/4.23 GiB
> (cannot remember the correct number, but high!)
> After a repack [1]: ~755 MiB
>
> The command I used: `git gc --aggressive --prune=now`
>
> I think we should schedule that command on the git server (it took
> around 3 hours on a small VPS) to reduce its size.
>
> I am available if you need any helps for that task.
>
> Cheers,
> Jonathan
>
> PS: you may need to increase the windowMemory value with: `git config
> --global pack.windowMemory 256m`
>
> [1] https://git-scm.com/docs/git-repack
>
> Spoiler: After removing the po file, and a repack, the repo index size is
> 127MiB
> ___
> 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/
>
___
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/

[Koha-devel] 18.05.14 Released

[Liz Rea]

Kia ora koutou,

The Koha community is pleased to announce the maintenance release of Koha
version 18.05.14. This is a security release, all users of 18.05 are
suggested to update to this version as soon as possible.

Full release notes can be found at
https://koha-community.org/18-05-14-released/ as well as download links.

Thanks to Lucas Gass (previous 18.05 maintainer), Martiin Renvoize, and
Chris Cormack for helping get this release out the door.

Be well everyone,
Liz Rea
___
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] Website: Update needed on some of the mailing lists viewers

[Liz Rea]

Hi,

I've just made these changes, thanks for pointing it out!

Liz

On Tue, Mar 19, 2019 at 1:55 AM Victor Grousset <
victor.grous...@biblibre.com> wrote:

> Hi :)
>
> https://koha-community.org/support/koha-mailing-lists/
> > If anyone else is running a Koha list and would like it added, please
>  > join and send a note to the Koha Developer’s List above.
>
> So I guess update requests should be also sent here.
>
>
> https://www.mail-archive.com/find.php?q=koha
> => not found
> solution: update the URL
> https://www.mail-archive.com/search?l=all=koha
>
> http://web.archiveorange.com/
> => hosts another thing unrelated now
>
>
> --
> Victor Grousset, dev support/maintenance
> BibLibre, Services en logiciels libres pour les bibliothèques
> BibLibre, Libre/Open Source software and services for libraries
> ___
> 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/

Re: [Koha-devel] Koha community site Wordpress issue

[Liz Rea]

Have been in contact with Chad, but haven't heard anything yet. The latest
wordpress upgrade broke both the editor and the permissions plugin we were
using, both seem to be working ok for me after a bit of fixing.

Cheers,
Liz

On Sat, Mar 2, 2019 at 2:56 PM kohanews  wrote:

> The Wordpress site koha-community.org will not save my edits and I'm
> unable to publish.
>
> Anyone know who manages that?
>
> Thank you!
>
> --
> Chad Roseburg
> Editor, Koha Community Newsletter
>
> ___
> 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/

Re: [Koha-devel] Questions about terminology

[Liz Rea]

Personally, I'd probably convert any "Biblio number" into
"Biblionumber," and if that needs explaining, it's the "Koha internal
record number" or "Koha unique record identifier"


On 23/10/18 09:02, Barton Chittenden wrote:
> On Mon, Oct 22, 2018 at 3:39 PM Liz Rea  wrote:
>
>> The term bibliographic number is easily confused with "inventory number"
>> and any local or old internal record numbers that migrated MARC may have.
>>
> Agreed,  bibliographic number is confusing.
>
>> I think the most accurate long form  representation is "Koha internal
>> record number", as the biblionumber has nothing at all to do with MARC, and
>> wouldn't necessarily be carried over to another system if the record was
>> moved (not that anybody would *leave* Koha, amirite).
>>
>> With that in mind, I don't see why we would need to drop biblionumber at
>> all - it references exactly what it is, is specific to Koha, and can be
>> understood and trained in that context, fully independent of MARC.
>>
> I think the use of biblionumber is fine in context -- that's generally used
> specifically when database tables are being mentioned. The term 'Biblio
> number' (containing a space) is what I'm more concerned about. I don't know
> that the marc editor was the only place that I saw that used.
>

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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] Questions about terminology

[Liz Rea]

The term bibliographic number is easily confused with "inventory number" and any local or old internal record numbers that migrated MARC may have. I think the most accurate long form  representation is "Koha internal record number", as the biblionumber has nothing at all to do with MARC, and wouldn't necessarily be carried over to another system if the record was moved (not that anybody would *leave* Koha, amirite).With that in mind, I don't see why we would need to drop biblionumber at all - it references exactly what it is, is specific to Koha, and can be understood and trained in that context, fully independent of MARC.On 23 Oct 2018 05:27, Barton Chittenden  wrote:On Mon, Oct 22, 2018 at 10:14 AM Owen Leonard  wrote:> I'm starting with looking for instances of 'biblio', which should be 'Bibliographic record'.

Hopefully Bug 19833 took care of (most of?) them.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19833I found a dozen or so in master. > I'm wondering about instances of "Biblio number" in the text... I think that
> "Bibliographic number" is actually *less* clear... "Bibliographic Record Number"
> is better, but in most cases where Biblio number is used (e.g. the Marc Editor),
> Biblio number makes sense in its context.

As a human-readable term I prefer "Bibliographic record number."
However, operations which reference biblionumber should all be fairly
technical, and thus a technical term might be appropriate. I'm curious
what edge cases there might be that don't fall into the "technical"
category.Most of the ones that I found were via grepping, I'm going to be looking at them in more detail shortly, so I'll have more context. 
On the other hand, if we expect these more technical users to know
what biblionumber is... how did they learn?I'm guessing that most probably learn from the URL or the database schema/reports library. It depends on level of expertise, I'm sure. I suppose I could ask on the koha general mailing list...--Barton 
___
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 users wiki page outdated, use HEA

[Liz Rea]

On 23/08/18 19:27, Paul Poulain wrote:
> Hello Liz,
>
>
> Le 23/08/2018 à 04:39, Liz Rea a écrit :
>> Hi Paul,
>>
>> No objection really, using Hea is a good thing and I recommend
>> libraries enable it. We should make asking about enabling it the last
>> step of the onboarder [is it there already? I forget...]. :)
>>
>> What I would like to see, is a lighter weight checkin to hea, where
>> if you (or your IT department) were feeling a bit wary about sending
>> all of your syspref stats to Hea, you could send only your Library
>> name and contact information, if desired (Koha could, of course,
>> provide things like the currently running version) as a one off.
> This idea sounds surprising to me: sharing sysprefs in anonymous way
> look less sensible than sharing library & contact. That's why we wrote
> HEA with only 3 options: share nothing / share data anonymously
> (including syspref) / share everything.
> In your idea, what about numbers already shared (like # of biblios,
> patrons, issues, ...) ? should they be sent with syspref or with
> library name/contact ?
> OTHER : do you think it's an option that will result in more libraries
> being on HEA ?

I do feel like having just the name and the contact information, as a
one off submission, would result in more libraries being listed in Hea -
especially if it's the last step in the onboarder at installation time,
and available say, to do later from the about page. could add a default
news item pointing to the preferences to turn it on and/or register your
library with the community.

IT departments are weird sometimes, what can I say. ^.^

>> I recognise this is a feature request for Hea :D and I think I'd be
>> happy at some stage to build the bits into Koha that were required to
>> have the feature, if it seems like something desirable to have in
>> addition to the auto reporting.
>>
>> I have other ideas about how one-off data could be used too, for
>> example you could flag those libraries if they never updated
>> automatically (or done an additional one off submission later) in Hea
>> "this library hasn't reported in for a long time - this entry may be
>> suspect." Those could be in an entirely separate list, too. Could
>> also email the contact automatically "hey update your entry if you're
>> still using Koha!"
> Good news: we store the "last update timestamp" on the server. So we
> can do that really easily ;)
>

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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 users wiki page outdated, use HEA

[Liz Rea]

Hi Paul,

No objection really, using Hea is a good thing and I recommend libraries 
enable it. We should make asking about enabling it the last step of the 
onboarder [is it there already? I forget...]. :)


What I would like to see, is a lighter weight checkin to hea, where if 
you (or your IT department) were feeling a bit wary about sending all of 
your syspref stats to Hea, you could send only your Library name and 
contact information, if desired (Koha could, of course, provide things 
like the currently running version) as a one off.


I recognise this is a feature request for Hea :D and I think I'd be 
happy at some stage to build the bits into Koha that were required to 
have the feature, if it seems like something desirable to have in 
addition to the auto reporting.


I have other ideas about how one-off data could be used too, for example 
you could flag those libraries if they never updated automatically (or 
done an additional one off submission later) in Hea "this library hasn't 
reported in for a long time - this entry may be suspect." Those could be 
in an entirely separate list, too. Could also email the contact 
automatically "hey update your entry if you're still using Koha!"


We all know that wiki pages are out of date the moment you click Save, 
so using Hea really is the best way to register Koha usage for any 
library. I just want it to be comfortable for every library to submit as 
much or as little information as they are comfortable with.


Cheers,

Liz


On 23/08/18 00:04, Paul Poulain wrote:


Hello all,

I sent an email to anyone listed on 
https://wiki.koha-community.org/wiki/KohaUsers/Europe, asking to 
update the reference, and explain HEA.


I got something like 15 bounces "email does not exist". I tried to 
reach OPACs for each of them (when on the wiki page).


I removed references that : have been bounced, have OPAC not reachable 
anymore, a very old version declared.



Le 09/07/2018 à 09:22, Paul Poulain a écrit :


Hello,

someone pointed me the https://wiki.koha-community.org/wiki/KohaUsers 
page.


The French libraries you can see here are so outdated that it's 
funny: most libraries are supposed to be in version 2.x, supported by 
me (not BibLibre. So more than 10 years old data...)


Other pages are also highly outdated, almost nothing with the current 
version numbering schema. And now we have HEA (available since 3.18 IIRC)


I propose to:

  * drop an email to all contacts saying "you're the contact for the
wiki page https://wiki.koha-community.org/wiki/KohaUsers, the
information here is outdated, please activate HEA (<>)"
  * update the wiki pages to add a big warn on top of each, saying
"this page is outdated, see hea.koha-community.org")

Any objection ?


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


___
Koha-devel mailing list
Koha-devel@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/

Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

[Liz Rea]

The easy answer is : leave it alone for existing installs, default it on 
for new ones.




On 20/06/18 12:19, David Cook wrote:


I think that’s not a bad way of looking at it. If people do complain, 
we can say that the change away was because of a commitment to patron 
security and privacy. I would hope that people would find that 
difficult to argue against.


If I recall correctly, I think DSpace does it this way. When you 
create a new user, I think it sends an email containing a URL with a 
token to the user, and then they set their own password from there. It 
works pretty well. Surely we could say “everybody else is doing it” as 
well.


But I know that there are a lot of libraries using this feature, and 
it would be disruptive to their existing workflows for it to go away. 
But… that’s also progress for you. So long as people have notice that 
it’s going away before the upgrade, they’d have time to change their 
workflows and adapt to a safer way of doing things?


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

*From:*Chris Cormack [mailto:chr...@catalyst.net.nz]
*Sent:* Wednesday, 20 June 2018 10:12 AM
*To:* koha-devel@lists.koha-community.org; David Cook 
; 'Liz Rea' 
*Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email 
via message queue?


We could make a list of them. It could be the "libraries who don't 
care about their users privacy" list.


I'm only mostly joking

Chris

On June 20, 2018 12:06:52 PM GMT+12:00, David Cook 
mailto:dc...@prosentient.com.au>> wrote:


I think that would probably be the best way of going about it, but
I’m sure there are a lot of libraries that wouldn’t be happy about
it.

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

*From:*koha-devel-boun...@lists.koha-community.org
<mailto:koha-devel-boun...@lists.koha-community.org>
[mailto:koha-devel-boun...@lists.koha-community.org] *On Behalf Of
*Liz Rea
*Sent:* Tuesday, 19 June 2018 12:26 PM
*To:* koha-devel@lists.koha-community.org
<mailto:koha-devel@lists.koha-community.org>
*Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS
email via message queue?

I feel like instead of sending people a password, we should send
them to the "forgot password reset page" with a couple of slight
changes for new account holders, so they can set their own passwords.

Seems better than sending the password in the clear in an email.

Cheers,
Liz

On 19/06/18 12:21, David Cook wrote:

Cheers, Jonathan. I had totally forgotten about that. Yikes.

  


Good call, Chris. While I think many mail servers these days use TLS to 
secure the email between the mail servers, an unscrupulous administrator could 
still certainly take advantage of people on either end. The best idea probably 
is to just not use AutoEmailOpacUser, as Jonathan seems to suggest.

  


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

  


Office: 02 9212 0899

Direct: 02 8005 0595

  


From: Jonathan Druart [mailto:jonathan.dru...@bugs.koha-community.org]

Sent: Tuesday, 19 June 2018 12:07 AM

To: Christopher Nighswonger 
<mailto:chris.nighswon...@gmail.com>

Cc: David Cook <mailto:dc...@prosentient.com.au>; 
Koha Devel
<mailto:koha-devel@lists.koha-community.org>

Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via 
message queue?

  


It has been reported (by David) on our bug tracker already (20796, 
security area, which does no longer make sense at it is public now...)

  


For information this notice contains the password in clear for... 10 
years now (bug 2149) and the behavior is turned off by default 
(AutoEmailOpacUser).

  

  


On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger mailto:chris.nighswon...@gmail.com>  <mailto:chris.nighswon...@gmail.com>
<mailto:chris.nighswon...@gmail.com>  > wrote:

Considering that email is plaintext (AKA "postcard") mail, I'm 
surprised we would send a user's password in an email in any case.

  

  


On Mon, Jun 18, 2018 at 4:14 AM, David Cook mailto:dc...@prosentient.com.au>  <mailto:dc...@prosentient.com.au>
<mailto:dc...@prosentient.com.au>  > wrote:

Considering that the borrower’s password is typically in the 
ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a 
bad idea and would probably violate the GDPR in Europe.

Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

[Liz Rea]

I feel like instead of sending people a password, we should send them to
the "forgot password reset page" with a couple of slight changes for new
account holders, so they can set their own passwords.

Seems better than sending the password in the clear in an email.

Cheers,
Liz


On 19/06/18 12:21, David Cook wrote:
> Cheers, Jonathan. I had totally forgotten about that. Yikes.
>
>  
>
> Good call, Chris. While I think many mail servers these days use TLS to 
> secure the email between the mail servers, an unscrupulous administrator 
> could still certainly take advantage of people on either end. The best idea 
> probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest. 
>
>  
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>  
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>  
>
> From: Jonathan Druart [mailto:jonathan.dru...@bugs.koha-community.org] 
> Sent: Tuesday, 19 June 2018 12:07 AM
> To: Christopher Nighswonger 
> Cc: David Cook ; Koha Devel 
> 
> Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via 
> message queue?
>
>  
>
> It has been reported (by David) on our bug tracker already (20796, security 
> area, which does no longer make sense at it is public now...)
>
>  
>
> For information this notice contains the password in clear for... 10 years 
> now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).
>
>  
>
>  
>
> On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger 
> mailto:chris.nighswon...@gmail.com> > wrote:
>
> Considering that email is plaintext (AKA "postcard") mail, I'm surprised we 
> would send a user's password in an email in any case.
>
>  
>
>  
>
> On Mon, Jun 18, 2018 at 4:14 AM, David Cook  <mailto:dc...@prosentient.com.au> > wrote:
>
> Considering that the borrower’s password is typically in the ACCTDETAILS 
> email, I think using the message_queue for ACCTDETAILS would be a bad idea 
> and would probably violate the GDPR in Europe.
>
>  
>
> Just imagine looking through your database and seeing all those plain text 
> passwords, especially for people who re-use the same password for everything. 
> I think it would be a security and privacy nightmare.
>
>  
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>  
>
> Office: 02 9212 0899  
>
> Direct: 02 8005 0595  
>
>  
>
> From: koha-devel-boun...@lists.koha-community.org 
> <mailto:koha-devel-boun...@lists.koha-community.org>  
> [mailto:koha-devel-boun...@lists.koha-community.org 
> <mailto:koha-devel-boun...@lists.koha-community.org> ] On Behalf Of Sophie 
> Meynieux
> Sent: Friday, 15 June 2018 9:33 PM
> To: koha-devel@lists.koha-community.org 
> <mailto:koha-devel@lists.koha-community.org> 
> Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via 
> message queue?
>
>  
>
> Maybe because for this message you're expecting it is sent immediately while 
> message_queue table could be processed more occasionally ? 
>
> Best regards
>
> S. Meynieux
>
>
>
> ___
> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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] MariaDB and Auto Increment - it's the good news

[Liz Rea]

I was quite nosing around looking for something else, and came across this:

|> Until MariaDB 10.2.3, InnoDB and XtraDB used an auto-increment counter
that is stored in memory. When the server restarts, the counter is
re-initialized to the highest value used in the table, which cancels the
effects of any AUTO_INCREMENT = N option in the table statements. |||

Of course. We knew that. What we didn't know, possibly, was the following:

||

|> From MariaDB 10.2.4, this restriction has been lifted and
AUTO_INCREMENT is persistent.|

||


Note that this isn't the current package version of mariadb-server for
Debian 9, it's lagging behind a bit at 10.1.26. However, the days of
auto increment issues, at least for MariaDB, may soon be coming to a close.

Information from: https://mariadb.com/kb/en/library/auto_increment/


-- 

Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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: avoid storing unencrypted passwords in gitconfig

[Liz Rea]

Deep approval, nice!

Liz


On 17/01/18 23:14, Julian Maurice wrote:
> Hi all,
>
> I recently shared an LXD container containing my Koha dev environment,
> and of course I forgot to remove my Bugzilla credentials from the git
> config...
> I immediately changed it, but for that not to happen again I searched
> for a way to not have to store unencrypted passwords for git-bz.
>
> The result is here https://github.com/jajm/git-bz/tree/git-credential
>
> It uses git-credential, so you can theoretically use any password
> manager you want, as long as you can write a git-credential helper for
> it (I use the builtin 'cache' helper, which stores passwords in memory)
>
> I thought it might interest some people here.
>
> For more information, see the commit message at
> https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57
>

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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] Best place for test plans

[Liz Rea]

Strong agreement from me for "have the test plan in the commit message." 

Bugs in bugzilla do get messy, but as long as we are applying the latest
patch, the plans are always right there for you to look at. Also for
everyone else to look at. And immortalized in git.

Git. They go in git, and by extension, on the patches attached to Bugzilla.

Cheers,
Liz



On 04/10/17 19:55, Marc Véron wrote:
> Hi David
>
> I think it is a good practice to have the test plan as commit comment
> and to obsolete any comments that are related to obsoleted patches. In
> Bugzilla, comments can be obsoleted by entering the keyword 'obsolete'
> as tag and then hit the return key.
>
> Marc
>
>
> Am 04.10.2017 um 01:56 schrieb David Cook:
>>
>> Hi all,
>>
>> I’ve been wondering about the best place to put test plans. I think
>> traditionally we include them in our git commits, but I feel like it
>> would be better to include them as standalone comments in Bugzilla.
>>
>> My reasoning is that finding test plans can be really difficult when
>> you’re scrolling back through numerous autogenerated per-commit
>> comments. And if there is lots of rebasing or modifications, you wind
>> up with a million test plans, so you can’t even Ctrl + F really.
>>
>> I figure when a patch is ready for testing, the developer should
>> write 1 comment containing all test plan instructions and post it to
>> the bottom of Bugzilla. That way, testers can just Ctrl + F for test
>> plan, find the lowest one, and just consider that in their testing.
>>
>> What do you all think?
>>
>> David Cook
>>
>> Systems Librarian
>>
>> Prosentient Systems
>>
>> 72/330 Wattle St
>>
>> Ultimo, NSW 2007
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Direct: 02 8005 0595
>>
>>
>>
>> ___
>> Koha-devel mailing list
>> Koha-devel@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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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.22, Plack & EDS plugin

[Liz Rea]

The problem here is that the plugin has a problem, and erroring plugins
don't show up in the intranet (ask me how I know ;))

You can get around it by commenting out the use C4::Branches in EDS.pm,
but the search still may not work. We have filed a bug with EBSCO about
it (well, Magnus did one on Github and we Catalyst emailed them about it).

https://github.com/ebsco/edsapi-koha-plugin/issues/15

There is also a bug to improve error handling for the plugins:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17461

It's not perfect but it is a LOT better than what happens now.

Cheers,
Liz, of the still sore forehead.

On 08/02/17 20:13, Hugo Agud wrote:
> Good morning
>
> There is any new on this? we have tried to install EDS plugin to Koha, but
> it doesn't appear on the intranet (I guess because of plack) , but there is
> on the plugin folder... I am going to contact ebsco, but if any body wish
> to share some info on it... I will pass to EBSCO
>
> Kindest Regards
>
> 2016-11-22 16:33 GMT+01:00 SUZUKI Arthur <arthur.suz...@univ-lyon3.fr>:
>
>> Some of the tricks used to integrate code from an intranet plugin on OPAC
>> are explained here.
>>
>> https://github.com/bywatersolutions/koha-plugin-coverflow#setup
>>
>> This "Setup" part explains quite well the Apache config modifications
>> needed to let users access coverflow.pl from OPAC, and why does this "
>> coverflow.pl" exist.
>>
>> the EDS plugin documentation lacks this information about Apache conf.
>>
>> (actually it doesn't but it is digged really deep :
>> https://github.com/ebsco/edsapi-koha-plugin/wiki/Apache-Setup)
>>
>> Le 22/11/2016 à 16:12, Paul Poulain a écrit :
>>
>>> Hi Arthur,
>>>
>>> The intranet part of the "plugin" is a plugin, so yes, it goes into the
>>> scope of Plack.
>>>
>>> But the eds-*.pl files (https://github.com/ebsco/edsa
>>> pi-koha-plugin/tree/master/Koha/Plugin/EDS/opac) don't. That's the OPAC
>>> part of the "plugin", that is not really a plugin
>>>
>>>
>>> Le 22/11/2016 à 15:49, SUZUKI Arthur a écrit :
>>>
>>>> Hello Paul,
>>>>
>>>> I don't know much about EDS nor Plack but I've been playing with koha
>>>> plugin functionality lately.
>>>>
>>>> I guess you're talking about this plugin :
>>>> https://github.com/ebsco/edsapi-koha-plugin
>>>>
>>>> does the koha plugin directory falls in the Plack scope?
>>>>
>>>> If koha is installed from Source, this directory is
>>>> "$KOHA_USERDIR/var/lib/plugins/"
>>>>
>>>> (I don't know for debian package, but probably something like
>>>> /var/lib/koha/plugins)
>>>>
>>>> Hope this helps.
>>>>
>>>> Arthur
>>>>
>>>> Le 22/11/2016 à 15:17, Paul Poulain a écrit :
>>>>
>>>>> Hello friends,
>>>>>
>>>>> We've deployed Koha 3.22, running Plack and the EDS plugin, and it
>>>>> appears that it does not work. We think it's because there are some .pl
>>>>> code that is out of plack scope, so it's not run. Is there anyone here who
>>>>> has some experience with koha / Plack / EDS ?
>>>>>
>>>>> (Frido will probably send a patch to Ebsco in the next days if there's
>>>>> no other ida)
>>>>>
>>>>>
>>>>>
>> --
>> Arthur SUZUKI
>> Service informatique des bibliothèques
>> BIBLIOTHÈQUES UNIVERSITAIRES
>> Université Jean Moulin Lyon 3
>> 6 Cours Albert Thomas - B.P. 8242 – 69355 Lyon Cedex 08
>> ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr
>> L'Université Jean Moulin est membre fondateur de l'Université de Lyon
>>
>> ___
>> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House,
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7



signature.asc
Description: OpenPGP digital signature
___
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] Developers, expect patches to no longer apply

[Liz Rea]

Not to mention that the move marcxml change will render a lot of reports
in the library, and in saved reports, non-functional.

Probably worth putting in the release notes.

Cheers,
Liz

On 19/01/17 01:58, Josef Moravec wrote:
> Not at all!
>
> wiki page https://wiki.koha-community.org/wiki/Interface_patterns was
> updated - see sections Buttons and Modals
>
> J.
>
> st 18. 1. 2017 v 12:32 odesílatel Kyle Hall <kyle.m.h...@gmail.com> napsal:
>
>> Thanks Josef!
>>
>>
>> <https://secure2.convio.net/cffh/site/Donation2?df_id=1395_ID=4715_ID=2706639_TYPE=20&1395.donation=form1_src=CHORUS_subsrc=CHAADOEB>
>>
>> http://www.kylehall.info
>> ByWater Solutions ( http://bywatersolutions.com )
>> Meadville Public Library ( http://www.meadvillelibrary.org )
>> Crawford County Federated Library System ( http://www.ccfls.org )
>>
>> On Fri, Jan 13, 2017 at 11:10 AM, Josef Moravec <josef.mora...@gmail.com>
>> wrote:
>>
>> Hello all,
>>
>> due to bug 16239 you'll need adapt your templates a bit, but it's mostly
>> just using other classes for buttons and also different syntax for modals:
>>
>> documentation here:
>> http://getbootstrap.com/css/#buttons
>> http://getbootstrap.com/javascript/#modals
>>
>> you can look to my followup up for 17898 to see how the typical change
>> looks like
>>
>> wiki page will be updated asap ;)
>>
>> Josef
>>
>>
>>
>> pá 13. 1. 2017 v 15:44 odesílatel Kyle Hall <kyle.m.h...@gmail.com>
>> napsal:
>>
>> Hey all,
>>
>> I just wanted to alert everyone to that fact that I just pushed the
>> following bug patches:
>> Bug 16239 - Upgrade Bootstrap in the staff client
>> Bug 17196 - Move marcxml out of the biblioitems table
>>
>> I expect this will cause a good number of patches to no longer apply with
>> hopefully trivial fixes required.
>>
>> Kyle
>>
>> http://www.kylehall.info
>> ByWater Solutions ( http://bywatersolutions.com )
>> Meadville Public Library ( http://www.meadvillelibrary.org )
>> Crawford County Federated Library System ( http://www.ccfls.org )
>> ___
>> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7



signature.asc
Description: OpenPGP digital signature
___
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] feature for bugzilla ?

[Liz Rea]

Maybe obsolete the comment of the patch that git-bz obsoletes?

We almost always (almost.) leave the original test plan in the signed
off patch, so I'm not certain we lose anything by obsoleting the comment
of the obsoleted patch.

It's probably worth noting that a comment can be untagged too.

Liz

On 19/12/15 04:11, Owen Leonard wrote:
>>> next step : obsoleting comment when you obsolete a patch ;-)
>>> (or even: always obsolete comments that are patch upload)
>> Perhaps git-bz could be made to do this?
> I don't think we should always obsolete comments on attachments. I
> like seeing the comment which is added by a patch because I want to be
> able to see the test plan in the commit message.
>
>   -- Owen
>

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7




signature.asc
Description: OpenPGP digital signature
___
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] Bug 1993 - Task Scheduler Needs Re-write

[Liz Rea]

I would love to see a proper queuing system used for this, maybe
introduce a really nice solution here that we can apply across the board
for other things that need queuing. I'm thinking things like zebra
updates, sending checkin/checkout emails, and others I'm sure I'm not
thinking of.

The at based scheduler has a really nasty bug on ubuntu 14/apache2.4
where the task scheduler doesn't work at all (see bug 14774). I am
absolutely not opposed to replacing the current scheduler for reports.

Cheers,
Liz

On 28/10/15 01:31, Jonathan Druart wrote:
> Hum, you can forget that :)
>
> 2015-10-27 12:29 GMT+00:00 Jonathan Druart
> <jonathan.dru...@bugs.koha-community.org>:
>> Julian,
>>
>> Have a look at bug 14435.
>> If you want to store report results, it could interest you :)
>>
>> Cheers,
>> Jonathan
>>
>> 2015-10-27 10:20 GMT+00:00 Julian Maurice <julian.maur...@biblibre.com>:
>>> Hi,
>>>
>>> Comments in bug 1993 state that using 'at' for task scheduling is bad
>>> for security.
>>>
>>> Galen suggests (comment 34) to use a DB table to store a list of jobs,
>>> and check periodically this list with a script in crontab.
>>>
>>> I would like to know if someone is already working on something like
>>> that (I didn't find anything in Bugzilla).
>>> If not, do you agree with Galen's proposal as a replacement for the task
>>> scheduler ? Do you have better ideas ?
>>>
>>> --
>>> Julian Maurice <julian.maur...@biblibre.com>
>>> BibLibre
>>> ___
>>> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7




signature.asc
Description: OpenPGP digital signature
___
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] IMPORTANT: Plack stress test server

[Liz Rea]

listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
> --
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io<http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
>
>
> --
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io<http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
>
> ___
> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7



signature.asc
Description: OpenPGP digital signature
___
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] Issue tracker for koha-qa.pl tool

[Liz Rea]

Gitlab, please!

On 29/09/15 09:43, Mason James wrote:
> Hi Folks
>
> Jonathan and I are planning to use an bug/issue tracker for the
> koha-qa.pl tool
> We thought it would be a good idea to get some opinions from other
> Koha developers, on which tracker to use
>
> here is the list we currently have...
>
> 1/ use github.com
> 2/ use gitlab.com
> 3/ use a KC.org gitlab server (can someone provide a 2gig server?)
> 4/ use current KC.org bugzilla
> 6/ something else...?
>
>
> any opinions?
>
> Mason
> ___
> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7




signature.asc
Description: OpenPGP digital signature
___
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] Install master on debian jessie

[Liz Rea]

Anything outside of the /var/www directory will need a directory
directive similar to:


Options Indexes FollowSymLinks
AllowOverride None
Require all granted


in Apache 2.4.

I stuck mine in apache2.conf, but I think you can stick it in
conf-available, which you would then enable with

sudo a2enconf filenameofyourconfigfile.conf

Worth trying anyway.

Liz
On 16/09/15 05:21, Michael Hafen wrote:
> You probably need to make sure there is a 'Require all granted' for the
> directory that the Koha git is in.
>
> On Tue, Sep 15, 2015 at 9:32 AM, Tajoli Zeno <z.taj...@cineca.it> wrote:
>
>> Hi to all,
>>
>> i'm try to install git master version on debian jessie.
>>
>> I installed modules using repo
>> deb http://debian.koha-community.org/koha stable main
>> [unstable doesn't work now]
>>
>> using the commands:
>> sudo apt-get install koha-deps
>> sudo apt-get install koha-perldeps
>> sudo apt-get install liblog-log4perl-perl
>> sudo apt-get install libplack-middleware-reverseproxy-perl
>> sudo apt-get install memcached
>>
>> then I do git clone, checked and installed perl dependecies.
>>
>> For apache I installed
>> sudo a2enmod rewrite deflate
>> sudo a2enmod cgi
>> sudo a2dissite 000-default
>> sudo a2ensite koha
>>
>> Now there problem on apache. The intranet log says:
>> [Tue Sep 15 17:25:04.573995 2015] [authz_core:error] [pid 7132] [client
>> 10.0.2.2:54862] AH01630: client denied by server configuration
>>
>> It seems connect with this change from 2.2 to 2.4:
>> http://httpd.apache.org/docs/2.4/upgrading.html -> Authorization
>>
>> I try to do the change
>>
>> from 2.2 configuration:
>>   Order deny,allow
>>   Deny from all
>>
>> to 2.4 configuration:
>>   Require all denied
>>
>> But it does't work.
>>
>> Do you have any more idea on the topic ?
>>
>> Bye
>> Zeno Tajoli
>>
>> --
>> Zeno Tajoli
>> /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche
>> Email: z.taj...@cineca.it Fax: 051/6132198
>> *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
>> ___
>> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7



signature.asc
Description: OpenPGP digital signature
___
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.18.10 released

[Liz Rea]

The Koha release team are proud to announce the release of Koha
3.18.10. This is a maintenance release and contains 1 security fix.
All Koha 3.18.x users are recommended to upgrade.

As always you can download at download.koha-community.org, or wait for
a few hours for the packages to be available.

Please read the full release notes at

http://koha-community.org/koha-3-18-10-released/

Thanks to all of our contributors for this release!

Cheers,

Liz
___
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] String freeze for Koha 3.18.10

[Liz Rea]

Hello fellow Kohackers,

The sun is shining, the sky is blue, it's a string freeze, that means
for you.

Bad rhymes aside, I won't be pushing any more string patches for 3.18.x
until after the release, and I'll let you know when I have updated .po
files from Bernardo. Then you can bring 3.18 properly up to date for
translations. :D

Cheers,
Liz

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7




signature.asc
Description: OpenPGP digital signature
___
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] Security release - Koha 3.18.8

[Liz Rea]

The Koha release team would like to announce the release of Koha 3.18.8
this is a security and a bugfix release.
Of special note in this release is that 3.18 is now compatible with
Debian Jessie. Go forth and upgrade your Squeeze boxes, ye users of
3.18!

As such we strongly recommend people running 3.18 should upgrade as soon
as possible

Special thanks also goes to Raschin Tavakoli and Dimitris Simos from SBA
Research for finding and reporting the security bugs.

Please go to http://koha-community.org/security-release-koha-3-18-8/
http://koha-community.org/security-release-koha-3-20-1/ to
read the full release notes.

Cheers,

Liz Rea
___
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] News area is gone

[Liz Rea]

Hi Luciana

This issue is caused by a bug in Koha:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12507

The good news is, it only happens on the last day of the month, and the
news will be back tomorrow. In other good news, the fix for it has
already been pushed into Koha upstream, so this problem won't occur once
you upgrade to an unaffected version (3.16.10, 3.18+).

If you need the contents of the news before tomorrow, you can look at
the news items directly in More - Tools - News - then select the news
item.

Cheers,
Liz



On 01/05/15 01:36, Luciana Coca wrote:
 Hello everyone!
 The News area have dissappeared.
 The configuration and preferences are correct. I have deleted and
 created new News, but nothing happend.
 Please, help me.

 Thank you all.
 Luciana.
 ___
 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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] Hidden items associated item types turning up in facets - anyone done work on this?

[Liz Rea]

Thank you all for your thoughts - feel free to continue to have them on
this topic. :)

Liz

On 27/04/15 11:54, David Cook wrote:
 Actually, now that I think about it, I suppose we could filter the facets
 whether they're using Zebra or the records themselves.

 It could slow things down, but I think it sounds like it wouldn't be too
 difficult. 

 David Cook
 Systems Librarian
 Prosentient Systems
 72/330 Wattle St, Ultimo, NSW 2007

 -Original Message-
 From: koha-devel-boun...@lists.koha-community.org [mailto:koha-devel-
 boun...@lists.koha-community.org] On Behalf Of Fridolin SOMERS
 Sent: Thursday, 23 April 2015 5:14 PM
 To: koha-devel@lists.koha-community.org
 Subject: Re: [Koha-devel] Hidden items associated item types turning up in
 facets - anyone done work on this?

 Whaou,

 This may be impossible to fix.
 Unless we create a new Zebra base for OPAC and remove in rebuild_zebra.pl
 hidden items and biblio when indexing.

 Regards,

 Le 22/04/2015 06:43, Liz Rea a écrit :
 Hi all,

 I'm just curious whether anyone has done work specifically on the
 hidden items and facets. I can see that there are bugs for hiding the
 associated item types from the Advanced Search, and quite a bit of
 work has been done to make the hiding more complete - but I wasn't
 able to find if anything had been done with the facets.

 Also quite curious if anyone has a thought on whether or not hiding
 associated item types will be easier or harder with 3.18+ (zebra
 facets).
 Please, share your thoughts!

 Cheers,
 Liz

 --
 Fridolin SOMERS
 Biblibre - Pôles support et système
 fridolin.som...@biblibre.com
 ___
 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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] Hidden items associated item types turning up in facets - anyone done work on this?

[Liz Rea]

Hi all,

I'm just curious whether anyone has done work specifically on the hidden
items and facets. I can see that there are bugs for hiding the
associated item types from the Advanced Search, and quite a bit of work
has been done to make the hiding more complete - but I wasn't able to
find if anything had been done with the facets.

Also quite curious if anyone has a thought on whether or not hiding
associated item types will be easier or harder with 3.18+ (zebra facets).

Please, share your thoughts!

Cheers,
Liz

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

___
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] Get Listed Paid Support Request

[Liz Rea]

This request has been completed.


On 22/04/14 14:03, Carlos Rodrigo Cordova Sandoval wrote:
 *Company Name: Open Geek Service*

 *Contact Person: Carlos Córdova*

 *Contact email: car...@opengeek.cl ccord...@opengeek.cl*

 *Website: http://www.opengeekservice.cl http://www.opengeekservice.cl/*

 *Telephone: *+569 6668 32 94

 *Address: Don luis manuel de zañartu 567, Puente Alto. Chile*

 *Short description of your services: We have two strong lines, one of them
 is the OPAC software, and the other, infraestructure and platform services
 based on Red Hat portfolio products.*

 *We work with VuFind and KOHA, and we implemented catalogs and services of
 these products in Chile, South America.*

 *http://www.opengeekservice.cl/sitio/bibliotecas/koha.html
 http://www.opengeekservice.cl/sitio/bibliotecas/koha.html*
 --
 -Carlos



 ___
 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/

Re: [Koha-devel] Architectural goals for 3.16

[Liz Rea]

On 11/12/13 05:40, Owen Leonard wrote:
 [4] Upgrade the version of Bootstrap we use to 3.x.
 As I mentioned in IRC today the primary caveat for this goal is that
 Bootstrap 3 says it drops support for Internet Explorer 7 and Firefox
 3.6. However, it doesn't explicitly say what dropping support
 means. If it means broken functionality, that is a problem for us. If
 it means graceful degradation, that's more acceptable. I'll be doing
 some investigation, but I think we need some opinions from others
 about what level of support we need to offer for IE7 and FF 3.6.

  -- Owen

(this is only my opinion, since you asked.)

IE 7 is only available in Windows XP, which is due to be end of life in
April 2014. Any changes we make for this cycle won't be released until
after XP is EOL. As noted in IRC, IE7 usage accounts for ~3% of counted
browser usage. In many ways, I feel that if Microsoft is refusing to
support IE7, that means we should feel ok in dropping our support for
IE7 as well. XP is an outdated, and dangerous operating system to be
running. Supporting IE7 feels like a vote of confidence in that platform
that is undeserved.

It should be noted that it was discovered that bootstrap 3 sites, though
not officially supported in FF 3.6, still seem to look and work OK.

--Liz






signature.asc
Description: OpenPGP digital signature
___
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] Z39.50 search results: DATE blank - add PUBLISHER

[Liz Rea]

Hi Andrea,

Thanks for your work on this. Do you think this is something that should
be put into Koha for all users? If so, you might consider filing a bug
at http://bugs.koha-community.org with this information.

Cheers,
Liz Rea

On 19/11/13 03:57, Andrea Furin wrote:
 1. If you have the field DATE blank when you make a Z39.50 search you
 have to modify the file:
 /usr/share/koha/lib/C4/Breeding.pm
 at line 394:
   $row_data{date} =  $oldbiblio-{copyrightdate};
 in
   $row_data{date} =  $oldbiblio-{publicationyear};
 (Make a copy of your modification becaurse probably ad update will
 change that file).

 2. If you want to see the publisher's name in Z39.50 results you have to
 add a line in:
 /usr/share/koha/lib/C4/Breeding.pm
 at line 394:
$row_data{server}   = $servername[$k];
$row_data{isbn} = $oldbiblio-{isbn};
$row_data{lccn} = $oldbiblio-{lccn};
$row_data{title}= $oldbiblio-{title};
$row_data{author}   = $oldbiblio-{author};
$row_data{date} = $oldbiblio-{publicationyear};
    $row_data{publisher}= $oldbiblio-{publishercode};
$row_data{edition}  = $oldbiblio-{editionstatement};

 and in:
 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/cataloguing/z3950_search.tt
 (change ../prog/LANGUAGE/modules/.. if not english)
 at line 155 the search results mask:
 thServer/th
 thTitle/th
 thAuthor/th
 thDate/th
 thPublisher/th
 thEdition/th
 thISBN/th
 thLCCN/th

 [Below the correspondet modified lines:]

 td[% breeding_loo.server %] div class=linktoolsa
 href=/cgi-bin/koha/catalogue/showmarc.pl?importid=[% breeding_loo.bree$
 td[% breeding_loo.title |html %]/td
 td[% breeding_loo.author %]/td
 td[% breeding_loo.date %]/td
 td[% breeding_loo.publisher %]/td
 td[% breeding_loo.edition %]/td
 td[% breeding_loo.isbn %]/td
 td[% breeding_loo.lccn %]/td
 ___
 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/




signature.asc
Description: OpenPGP digital signature
___
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 theme proposal

[Liz Rea]

+1 from me as well. Thanks for the coherent proposal, Galen.

Liz
On 30/10/13 07:53, Christopher Nighswonger wrote:
 +1


 On Tue, Oct 29, 2013 at 2:50 PM, Kyle Hall kyle.m.h...@gmail.com wrote:

 +1

 http://www.kylehall.info
 ByWater Solutions ( http://bywatersolutions.com )
 Meadville Public Library ( http://www.meadvillelibrary.org )
 Crawford County Federated Library System ( http://www.ccfls.org )
 Mill Run Technology Solutions ( http://millruntech.com )


 On Tue, Oct 29, 2013 at 10:18 AM, Joy Nelson 
 j...@bywatersolutions.comwrote:

 +1


 On Mon, Oct 28, 2013 at 8:58 PM, Nicole Engard neng...@gmail.com wrote:

 +1


 On Mon, Oct 28, 2013 at 6:17 PM, Tomas Cohen Arazi tomasco...@gmail.com
 wrote:
 +1

 Six month seems enough for adjusting the css anyway.

 El 28/10/2013 14:32, Galen Charlton g...@esilibrary.com escribió:

 Hi,

 Based on the feedback received last week, here is my current proposal
 for managing the OPAC themes:
 [1] We ship Bootstrap as the default theme for 3.14 for new
 installations.
 [2] We announce deprecation of prog and CCSR when 3.14 is released
 and issue a recommendation that libraries start switching to Bootstrap.
 [3] At the same time, we announce that prog and CCSR will be removed
 in 3.18.  If some organization wishes to maintain either theme after then,
 they can do so, but as a separate contrib.  However, if you are inclined 
 to
 support either theme after they've been removed ... please think carefully
 about the amount of work that would entail.
 [4] The RM will assist in getting OPAC template patches in the
 pipeline that were written for prog updated to support Bootstrap as well.
 [5] Starting with the 3.16, new OPAC patches should be targeted for
 Bootstrap first.  During the 3.16 cycle, contributors are requested to 
 make
 an effort to update the prog theme as well, particularly for new features,
 but this is a request, not a requirement.  In other words, this means that
 for 3.16, libraries may need to switch to Bootstrap to take full advantage
 of new OPAC functionality, but the prog theme will continue to be
 functional.
 [6] During the 3.18 cycle, no patches will be pushed for prog except
 insofar as they may be needed to fix security issues in the maintenance
 releases.  Before 3.18 is released, prog and CCSR will be taken out
 entirely.
 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 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/



 --
 Joy Nelson
 Director of Migrations

 ByWater Solutions http://bywatersolutions.com
 Support and Consulting for Open Source Software
 **Office: Fort Worth, TX
 Phone/Fax (888)900-8944
 What is Koha? http://bywatersolutions.com/what-is-koha/


 ___
 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/



 ___
 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/



signature.asc
Description: OpenPGP digital signature
___
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/

Re: [Koha-devel] Bugzilla: Reply on comment

[Liz Rea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've noticed on some websites (including Koha), pasting in without
putting something in manually like a space doesn't seem to activate the
submit buttons. You might try pasting, then hitting the space bar or
something and see if that helps.

Cheers,
Liz
On 04/07/13 01:02, Paul Poulain wrote:
 Le 03/07/2013 13:59, Marcel de Rooy a écrit :
 Hi all,
 I recently (last update?) and regularly have trouble with Reply on
Bugzilla.
 It does sometimes no longer paste the comment in the text box.
 Anyone else having this too? Or found a way to resolve it?

 Yep, I sometimes have this problem as well. But I haven't found how to
 fix it.
 I'm using Firefox with some modules like lazarus, stylish, greasemonkey,
 firebug that could have an impact.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR1JYfAAoJELbCpJ03Jji3cSAH/AgT+aVV4ebENJEdXVRkspJ2
hSYOEzrgBO64MXFgiJOMaglEXoZOctc3a/BCg/KdlYYxW+nC+6FoHn1JJd0LJlsF
2Vru9tS0OsXhbNG9WUyCQ4Il/e0ILbQHH3+QT6FfC8Sumlx/fVdBe3IBSnxVXh1p
illTW5HUS2q7iypxagcJ2M2YobcRAfrvAnSKWrpW5Y7F8DfT9v1f15wvpdVIVlMr
soglLxlteVeGupRykuYiKBDOKkzqTAax0Q1R/XghKrQMAJplgyStxIO7oFRypZSb
tdApZqA9Bo2XTRjIcxxtPgG2puz74pDv8/0Q7PmtkgmraPfPriN9KZaXoHNxvn0=
=SRFt
-END PGP SIGNATURE-

___
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] Translation Manager for 3.14

[Liz Rea]

Hi Bernardo,

I will take this as acceptance of the position, and update the wiki
accordingly.

Thanks so much for volunteering, and for your service.

Liz Rea
On 07/05/13 16:00, Bernardo Gonzalez Kriegel wrote:
 Hi all,
 I'm so sorry to have missed the meeting, my apologies.

 Anyway, I'm glad to have been elected, and expect to a do good
 job at that post.

 My sincere thanks for the opportunity,
 Bernardo



 ___
 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/

Re: [Koha-devel] Koha numbering

[Liz Rea]

http://koha-community.org/get-involved/irc/ may be the resource you are
looking for.

Cheers,

Liz Rea
On 08/04/13 10:07, Paul wrote:
 At 04:07 PM 4/7/2013 -0400, Jared Camins-Esakov wrote:

 But please do not jump from 3 to 14 !


 Good point. I added the following proposal to the agenda for the next
 IRC meeting:

 When does the vote take place, and how does one join in?  I've no
 experience whatsoever with IRC, what's needed for software (if
 anything?) Or is there another way to vote?

 Thanks - Paul


 * Vote on (NOT DISCUSS) the proposal to increment the major version
 for every feature release starting after version 3.14, which is due
 to be released on November 22, 2013 or so. This means that the
 version released on or about May 22, 2014 will be called Koha 4.0.0.
 (added by jcamins, but to be presented by someone who cares)

 If there is consensus that the vote should be on a different
 versioning scheme, that is absolutely fine with me, please change it
 on the agenda. I merely wrote the compromise position that I had the
 impression that people were leaning towards. As I state on the item,
 I will not be presenting the motion, but action beats talk ten times
 out of ten, so I took the step of adding it to the agenda so that it
 can be voted on.

 Regards,
 Jared

 -- 
 Jared Camins-Esakov
 Bibliographer, C  P Bibliography Services, LLC
 (phone) +1 (917) 727-3445
 (e-mail) jcam...@cpbibliography.com mailto:jcam...@cpbibliography.com
 (web) http://www.cpbibliography.com/
 ___
 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/ 

 ---
 Maritime heritage and history, preservation and conservation,
 research and education through the written word and the arts.
 http://NavalMarineArchive.com http://navalmarinearchive.com/ and
 http://UltraMarine.ca http://ultramarine.ca/


 ___
 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/

Re: [Koha-devel] Koha numbering

[Liz Rea]

I too was looking forward to 3.14. I'm happy to change it after that.

:P

Yes, ok, it's a sentimental thing but... it's PI. COME ON.

Liz


On Sat, Apr 6, 2013 at 9:48 AM, Nicole Engard neng...@gmail.com wrote:

 On Fri, Apr 5, 2013 at 2:28 PM, Galen Charlton g...@esilibrary.com wrote:

 Consequently, I'd be happy if we kept the 3.x series going
 indefinitely, or if we bumped up the major version number when it felt
 right, or if we dropped the 3. and called the fall release 13.0 or
 14.0.

 Whatever gets decided, I *do* strongly feel that we collectively
 promise to stick to it for at least three years -- and *not* discuss
 it further.


 In that case I vote for us to drop the 3 and go with the straight
 numbering.

 Nicole

 ___
 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/

Re: [Koha-devel] 3.8.10 on Ubuntu 12.04.2 LTS

[Liz Rea]

Hi Paul,

I believe SQLite is used for offline circulation. If you don't use that,
you should be all good.

Liz Rea


On 05/03/13 09:12, Paul wrote:
 Just finished a brand new (sandbox) install from tarball of 3.8.10 on
 a 64-bit Ubuntu 12.04.2 (note last digit) LTS server. All seems good,
 but have not had much time yet to play with it -- install went
 smoothly, no problems, 1 hour 35 mins from partitioning to fully
 functional copy of production db including our customizations.

 One question that I have not yet had time to fully look into, so I'm
 looking for pointers/suggestions, please.

 dpkg (ubuntu.12.04.packages) asks for libdbd-sqlite2-perl which is no
 longer available (except in the unsupported Universe repository),
 replaced by libdbd-sqlite3-perl which I installed. koha_perl_deps.pl
 -m gives the 2 version as missing - not required but after install
 AboutPerl modules highlights DBD::SQLite2 in bright pink!

 I haven't yet found any lack of functionality, but could one of you
 suggest a test that specifically calls this module? Or does the not
 required mean not in production machines? In which case the bright
 pink highlighting might be a bug - enhancement - low priority.

 Many thanks and best regards - Paul

 ___
 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/

[Koha-devel] Opinions needed on bug 9322

[Liz Rea]

I'm really not sure what the best solution is here - opinions?

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

I think we do not want to lose any data regarding transfers, no matter
how weird or nonsensical an action might be, a librarian might
legitimately want to do chained transfers, so we should not disallow
that. A librarian might also legitimately want to have a transfer and a
reserve going at the same time and choose between them at check-in time.

So what is the best way to fix this problem of multiple transfers from
multiple sources (branchtransfers and reserves transfers being the
different origins of transfers) being all cancelled when one is
completed? The current behaviour is blocking other very useful (and paid
for) development - and the bug itself causes librarians discomfort quite
often in the form of lost and stuck reserves.

Thanks for your time and thought,
Liz


___
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] Amazon Cover Images

[Liz Rea]

Library Thing is not free of charge (and possibly not very free as in
freedom, either), iirc. Certainly you can subscribe to Library Thing for
Libraries and/or syndetics for cover images, and those are ok. But you
still have a problem with covers for DVD's and such. Not that we could
get dvd covers ever from openlibrary.

Liz

On 21/02/13 15:50, Mason James wrote:
 On 2013-02-21, at 9:49 AM, Joe Atzberger wrote:

 On Mon, Feb 4, 2013 at 8:35 PM, Nicole Engard neng...@gmail.com wrote:

 On Mon, Feb 4, 2013 at 1:14 PM, Frédéric Demians frede...@tamil.fr wrote:

 Isn't Open Library the solution?

 Yes, but most libraries aren't picking Open Library cause the images are so 
 tini tiny :) So hopefully that is resolved in 3.12 or in a later 3.10 
 release so that I can start getting everyone to switch!!

 I regret to report that as of last week at #code4lib conference in Chicago, 
 the status of Open Library as a jacket image source is rather questionable.  
 It has not been loading updates since last summer and current development is 
 in unrelated areas areas of interest (e.g. ebooks).  It is unclear when this 
 production/maintenance will be picked up and by whom.  

 --Joe

 hey Joe, long time no chat :)

 wow, thats a bummer - OpenLibrary was looking like the best option for 
 everyone :/


 Joe, did anyone at #code4lib agree on a better option for the distant future, 
 library-thing perhaps?
 ___
 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/

Re: [Koha-devel] kc.org support companies page broken...

[Liz Rea]

http://koha-community.org/support/paid-support/country/#ind

seems to work for me?

Liz
On 15/02/13 01:42, Paul Poulain wrote:
 Hello,

 I tried to go to http://koha-community.org/support/paid-support/ to
 check for indian companies being listed here... and got a nasty no
 results.

 :\


___
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] Bug 8641

[Liz Rea]

That message shows up on the home page every time you log in with user 
0. It's in a giant yellow box.


See: http://imgur.com/kG8xunF

Hope that helps,

Liz Rea

On 24/01/13 11:26, Paul wrote:

At 10:48 AM 1/24/2013 +1300, Robin Sheat wrote:

Archives and Collections Society schreef op wo 23-01-2013 om 10:57
[-0500]:
 As far as I can see (using getent passwd | cut -d : -f 1 | xargs
 groups)
It's worth noting that there is absolutely, completely no relationship
between UNIX system users and Koha or MySQL users. Never the twain shall
meet.
When you log in with your database username and database password (i.e.,
the same thing you would use if you typed
mysql -u username -ppassword koha) then you are user 0. However, as
user 0 doesn't have an entry in the borrowers database, anything that
tries to look you up, or otherwise reference your record will get
terribly confused.
For our client Koha systems, I only ever user that user for doing quick
and dirty things, changing some admin settings, looking at the state of
something, creating initial borrowers. Anything more complex than that
is likely to have conniptions.


Many thanks Robin -- that was what I had assumed, but confirmation is 
always good to have. In fact, I have only ever used it to create the 
very first superlibrarian [1] on a new install.


May I make a suggestion regarding the sign-off to this bug? (It seemed 
a bit complex vis-a-vis translations, so I don't want to upset any 
apple carts.) It might be a good idea to add a para to the INSTALL 
files (general, Debian, Ubuntu, whatever) to alert people before they 
get the opportunity to click on About Koha. I've had a quick look at 
various 3.8 and 3.10 .tar files and don't find anything.


[1] Re: 'borrower' permissions. What's the difference between flag 1 
(plain superlibrarian) and flag '261887' (super librarian with all 
boxes checked)?  Is it necessary to check the boxes?


Again tnx and br,
Paul
___
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/

Re: [Koha-devel] Can we create templates for branches.

[Liz Rea]

I think what you want is not entirely impossible, but I can say that it 
would likely be a lot of work to maintain.


A few years ago we had a RFC for the following work, which was never 
done but I think would do something similar to what you are describing, 
and possibly be easier to maintain through upgrades:


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

Liz Rea
On 04/01/13 12:01, Quoc Uy wrote:
   My idea comes from creating 1 Koha installed with 1 
Database for 100 small branches libraries. Each branch has separated 
template OPAC.  There should be a folder in koha and logic in the 
application that saying ... ok, load branchA's template OPAC for 
BranchA's user when they login. A,B or C are diff branch 
libraries, they can have there own data set and can share if possible 
(it has done quite well with independent branches preference now). 
Hope some one can improve this! Sorry for my bad English!


Best regards!


___
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/

Re: [Koha-devel] [Koha] Koha 3.10.0 released

[Liz Rea]

Hiya,
Just to put this one to bed - odt files are now permissible as upload 
types on k-c.org.


:)

Happy Sunday/Monday!

Liz
On 01/12/12 00:15, Paul Poulain wrote:

Le 30/11/2012 12:01, MJ Ray a écrit :

Paul Poulain wrote:
If it's impossible, could you report the bug

I don't think it's a bug, it's just forbidden by k-c.org rule (security
reason ?)


and upload it somewhere
on biblibre.com for now, rather than crossposting big mails, please?

Yep, I realised, but after shooting the mail, that I could have created
a bug on bugzilla and uploaded it as attachment here.

Sorry for this 1MB attachment



___
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 Koha download pages, with some info for beginners

[Liz Rea]

+1 from me - the packages are mature enough at this point and well
documented enough to encourage most users to use them instead of a
tarball install.

Liz

On Mon, Nov 12, 2012 at 1:13 PM, Mason James m...@kohaaloha.com wrote:
 hi Folks

 can we get some info the following 2 pages, recommending beginners to install 
 Koha using the 'packages' method

 http://koha-community.org/download-koha/
 http://download.koha-community.org/


 it seems to me, these 2 pages are the first pages a beginner hits, when 
 attempting to install Koha
 if we can put some info recommending beginners to install Koha using the 
 'packages' method there, we can save everyone much wasted effort


 (i would, but i don't have edit permissions, afaict)


 so… is this a good idea, or not?


 ___
 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/

Re: [Koha-devel] Bugzilla component categories

[Liz Rea]

I'll keep my default assignment for Website issues. :)
Liz Real...@nekls.org

On May 2, 2012, at 7:10 AM, Marcel de Rooy wrote:Hi all,Recently we discussed in the QA team to make the default QA contact empty. (Ian cleared this field for all components now [for new reports].) In the process the QA team member that starts QA on a report now, enters his name in the QA contact field. This informs reporter, patch writer, etc. that QA started and is also helpful for other QA team members in order to prevent duplication of work.My question now is: Should we do something similar with the default Assignee per component? In practice, the current default assignees will (most of the time) not be working on reports entered by someone else. Having someone in the Assignee field who is not working on that report, could be a misleading signal for an unaware Bugzilla user. If the default assignee wants to be informed on reports of that category, moving him/her to the default CC list of that component would perhaps be better?The current default assignees are (for one or more components):neng...@gmail.comhenridam...@koha-fr.orggmcha...@gmail.comoleon...@myacpl.orgch...@bigballofwax.co.nzkyle.m.h...@gmail.comkoha.sek...@gmail.comfrede...@tamil.frcnighswon...@foundations.eduro...@catalyst.net.nzcolin.campb...@ptfs-europe.compaul.poul...@biblibre.comwizzy...@gmail.comWould you agreewith this move? (We need of courseconsensus before doing so.)Would you like to be added as default CC for one or more components?Please respond.Thanks,Marcel___Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-develwebsite :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/

Re: [Koha-devel] SQL reports [error]

[Liz Rea]

Yes! I have a proposal for possible changes to the web installer athttp://wiki.koha-community.org/wiki/Rfc_3.10_webinstaller_improvements- which includes the possibility to remove the ability of the db user to log in at all and force creation of a new admin superlibrarian at install time.l...@nekls.org

On Apr 30, 2012, at 10:59 AM, Chris Nighswonger wrote:On Mon, Apr 30, 2012 at 11:44 AM, Fischer, Katrin katrin.fisc...@bsz-bw.de wrote:

Hi Paul,

I really don’t like the idea. I think if you want someone to make changes to the database, you should give them a proper tool and training to do that (outside of Koha). The interface for statistics is very limited and does not give feedback when your SQL statements have errors or produce no result sets. Also it seems like a big security risk to me.I tend to agree with Katrin here.

I wonder if there is not even a better way to handle the installer so that the db user does not have to log into the interface at all?Kind Regards,Chris

___Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-develwebsite : 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/

Re: [Koha-devel] SQL reports [error]

[Liz Rea]

This is a pretty brilliant idea, imo. Perfect use for the tool.
Liz Real...@nekls.org

On Apr 30, 2012, at 12:41 PM, Eric Bégin wrote:
  

  
  
Paul,

Have you consider having your report generating a list of
barcodes and using this list in the Batch Item modification tool
to change the accesiondate ?

Regards,

Eric Bégin
www.inLibro.com
  
On 2012-04-30 09:13, Paul wrote:
Good morning all:
  
  
  I have no problem with the philosophy of the following (bright
  yellow) pop-up error message: "The following error was
  encountered: This report contains the SQL keyword UPDATE.
  
  Use of this keyword is not allowed in Koha reports due to security
  and data integrity risks." and would not even consider suggesting
  a "bug."
  
  
  However, it would be most helpful to staff for a very specific but
  repetitive job that we do at year end (batch changing
  items.accessiondate after Tax Receipts have been issued for
  donations) to be able to use Koha from a work station, rather than
  getting me to work directly on the production server (I've already
  been asked 50 or 60 times, and there's another 400+ to go ...!)
  
  
  Can anyone point me rapidly to the portion of script that I should
  have a look at?
  
  
  For the record, the CLI mysql in question is:
  
  
  UPDATE items
  
  SET dateaccessioned='2011-12-31'
  
  WHERE price IS NOT NULL and price != '0.00'
  
  AND booksellerid = 'xxx'
  
  AND DATE(dateaccessioned) BETWEEN '2011-01-01' AND '2011-12-31';
  
  
  Obviously for a report, I would use a construct for the last two
  conditions along the lines of:
  
  
  AND booksellerid = Pick your donor
  
  AND DATE(dateaccessioned) BETWEEN Accessioned BETWEEN
  (-mm-dd) AND and (-mm-dd);
  
  
  Thanks and best regards,
  
  Paul
  
  
  ___
  
  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 listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-develwebsite : 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/

Re: [Koha-devel] is there a full koha anonymized test database available to squash bugs against?

[Liz Rea]

I have one that is a combo of sample data and MARC21 data - you can get it athttps://github.com/wizzyrea/Scripts-and-Things/blob/master/kohadev-withbibs.sql.gz(do note, it's possible the rules in there are not quite sane or not defined in a way that makes sense. Step through the administration when you get it imported.)And just the marc data:https://github.com/wizzyrea/Scripts-and-Things/blob/master/MARC21.mrcI've got an ongoing project to make a collection of sample data, and rule sets that developers can choose and import at install time, but they are not ready quite yet. :)
Liz Real...@nekls.org

On Mar 21, 2012, at 12:45 AM, Mason James wrote:On 2012-03-18, at 4:52 PM, Waylon Robertson wrote:is there a full koha anonymized test database available to squash bugs against?as far as i know... nodoes anyone else know better?___Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-develwebsite : 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/

Re: [Koha-devel] Plea for help from Horowhenua Library Trust re: Koha

[Liz Rea]

It is so sad to see the gift you gave us all fall into unfriendly hands.

Do please let us know when the kitty is opened up for donations.

Liz Rea
l...@nekls.org

inline: email_signature.jpeg

On Nov 21, 2011, at 3:31 PM, Joann Ransom wrote:

 As I am sure most of you are aware, Horowhenua Library Trust is the birth 
 place of Koha and the longest serving member of the Koha community. Back in 
 1999 when we were working on Koha, the idea that 12 years later we would be 
 having to write an email like this never crossed our minds. It is with 
 tremendous sadness that we must write this plea for help to you, the other 
 members of the Koha community.
 
 The situation we find ourselves in, is that after over a year of battling 
 against it, PTFS/Liblime have managed to have their application for a 
 Trademark on Koha in New Zealand accepted. We now have 3 months to object, 
 but to do so involves lawyers and money. We are a small semi rural Library in 
 New Zealand and have no cash spare in our operational budget to afford this, 
 but we do feel it is something we must fight.
 
 For the library that invented Koha to now have to have a legal battle to 
 prevent a US company trademarking the word in NZ seems bizarre, but it is at 
 this point that we find ourselves.
 
 So, we ask you, the users and developers of Koha, from the birth place of 
 Koha, please if you can help in anyway, let us know.
 
 Regards,
 
 Jo.
 
 -- 
 Joann Ransom RLIANZA
 Head of Libraries,
 Horowhenua Library Trust.
 
 ___
 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/

Re: [Koha-devel] KohaAdminEmailAddress error - Koha 3.05

[Liz Rea]

After a bit of back and forth, I believe Mr. Hartman discovered a bug (or at least a limitation) in the patron update script.I went ahead and filed bug 6870 on his behalf, and submitted a patch for it that may help with his issue. Woohoo!
Liz Real...@nekls.org

On Sep 13, 2011, at 5:08 PM, Hartman, David W. - GBTS Library wrote:Thanks for the reply. :) i dont think thats it. The kohaadmin email we are using is a library email address and the user record was a non- library related individual user.Keep the thoughts coming! This is the last hurdle then I won't be bugging y'all ... And maybe I can help someone!Sent from my iPhone! Pardon typos, etc.On Sep 13, 2011, at 5:57 PM, "Liz Rea" l...@nekls.org wrote:Well, this is just a guess, so sorry if I'm way off here.Are these messages patron update emails? I wonder if you're testing the patron update notification with an account that has the same email address as your admin user, thus it *looks* like the to and from are the same. What's really happening, I think (totally not sure! At all!) is that it's sending the notice FROM the patron's user entered address, TO the koha admin email, which happen to be the same.Plausible?
Liz Real...@nekls.orgemail_signature.jpeg

On Sep 13, 2011, at 3:34 PM, Hartman, David W. - GBTS Library wrote:For sending emails …. Is there a way to make the To: and From: addresses different in the auto generated messages? I am getting error messages that we are sending to and from the same address.It looks like koha is using the admin address (KohaAdminEmailAddress) for both.I am wondering if there is a configuration setting we are missing.David W. HartmanGlobal Business Technology Strategy Library___Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-develwebsite :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/

Re: [Koha-devel] KohaAdminEmailAddress error - Koha 3.05

[Liz Rea]

Well, this is just a guess, so sorry if I'm way off here.Are these messages patron update emails? I wonder if you're testing the patron update notification with an account that has the same email address as your admin user, thus it *looks* like the to and from are the same. What's really happening, I think (totally not sure! At all!) is that it's sending the notice FROM the patron's user entered address, TO the koha admin email, which happen to be the same.Plausible?
Liz Real...@nekls.org

On Sep 13, 2011, at 3:34 PM, Hartman, David W. - GBTS Library wrote:For sending emails …. Is there a way to make the To: and From: addresses different in the auto generated messages? I am getting error messages that we are sending to and from the same address.It looks like koha is using the admin address (KohaAdminEmailAddress) for both.I am wondering if there is a configuration setting we are missing.David W. HartmanGlobal Business Technology Strategy Library___Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-develwebsite :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/

Re: [Koha-devel] Koha Load Testing

[Liz Rea]

I created the wiki page... go for it!

(great idea, by the way)

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

Liz
On Apr 14, 2011, at 10:23 AM, LAURENT Henri-Damien wrote:

 Le 14/04/2011 17:10, Ian Walls a écrit :
 Fellow Kohackers,
 Hi
 
 
 
 Do any of you have a favour script or suite of scripts (or even a
 method) for doing load testing against a Koha installation?  I know
 there are some scripts available in misc/load_testing, but my
 understanding is they aren't terribly useful or current.  Is that correct?
 quite.
 I did use ab and siege.
 But siege is my favourite.
 The nice thing with siege is that you can input a url file that will do
 the search with all the url provided.
 I used a TransferLog from apache, (One or two days) edited to suit the
 siege format for input and that was VERY useful for load testing.
 http://opac.distant/cgi-bin/koha/opac-search.pl?idx=q=l%27explosion+de+la+communication
 provides that kind of output
 
 ** SIEGE 2.70
 ** Preparing 30 concurrent users for battle.
 The server is now under siege...^C
 Lifting the server siege..  done.
 Transactions:  450 hits
 Availability:100.0 %
 Elapsed time:64.00 secs
 Data transferred: 2.82 MB
 Response time:4.25 secs
 Transaction rate: 7.03 trans/sec
 Throughput:   0.04 MB/sec
 Concurrency: 29.92
 Successful transactions:   31806
 Failed transactions: 0
 Longest transaction:  7.37
 Shortest transaction: 0.00
 
 The nice thing is that you can use -v to see which elements have errors.
 
 
 Something that can throw a user-configured amount of punishment at a
 Koha server, then report on the results, would be ideal.  The output
 should include both the user perspective (response times) and what's
 happening on the machine (memory/CPU usage, query times, etc) in the
 context of the machine's specifications.
 Having both in one software would not be possible unless you have a
 client and server script to do that... But then ... it could be like an
 auditer having some interests in the place. But I may be mislead.
 
 You can use munin or nagios to inspect the server while load testing.
 
 
 If all this data can be compiled for various configurations, I think
 we'd have the makings of a fine, evidence-based Koha Tuning Guide.
 
 We already have bits in the koha-devel list for that.
 We would need to compile those bits into an administration/setup guide
 though on the wiki. #idea
 Hope that helps.
 -- 
 Henri-Damien LAURENT
 BibLibre
 ___
 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/

Re: [Koha-devel] Koha print circulation slips

[Liz Rea]

Linda,
This configuration information may help you, it is what we do to configure our 
receipt printers to print automatically.

http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/

You can also do this with a version of portable firefox, used only for Koha, 
that has the receipt printer configurations built in. I'm happy to provide 
direction in how to get that working as well (there are a few tricks to it).

Liz Rea
NEKLS

On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:

 All,
 I am trying to find a way to print circulation slips (hold/checkout) 
 automatically.  Has anyone else tried to do this?
 Thanks!
 -- 
 Linda Culberson   lcul...@mdah.state.ms.us
 Archives and Records Services Division
 Ms. Dept. of Archives  History
 P. O. Box 571
 Jackson, MS 39205-0571
 Telephone:  601/576-6873
 Facsimile:  601/576-6824
 
 ___
 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/

Re: [Koha-devel] Koha print circulation slips

[Liz Rea]

This information can now be found on the Koha wiki as well, at 
http://wiki.koha-community.org/wiki/Configure_Automatic_Receipt_Printing

:)

Liz Rea
NEKLS

On Apr 13, 2011, at 8:57 AM, Linda Culberson wrote:

 What wonderfully detailed information! Thank you!
 Linda
 
 On 4/13/2011 8:47 AM, Liz Rea wrote:
 Linda,
 This configuration information may help you, it is what we do to
 configure our receipt printers to print automatically.
 
 http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/
 
 http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/You
 can also do this with a version of portable firefox, used only for Koha,
 that has the receipt printer configurations built in. I'm happy to
 provide direction in how to get that working as well (there are a few
 tricks to it).
 
 Liz Rea
 NEKLS
 
 On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:
 
 All,
 I am trying to find a way to print circulation slips (hold/checkout)
 automatically. Has anyone else tried to do this?
 Thanks!
 --
 Linda Culberson lcul...@mdah.state.ms.us mailto:lcul...@mdah.state.ms.us
 Archives and Records Services Division
 Ms. Dept. of Archives  History
 P. O. Box 571
 Jackson, MS 39205-0571
 Telephone: 601/576-6873
 Facsimile: 601/576-6824
 
 ___
 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/
 
 
 -- 
 Linda Culberson   lcul...@mdah.state.ms.us
 Archives and Records Services Division
 Ms. Dept. of Archives  History
 P. O. Box 571
 Jackson, MS 39205-0571
 Telephone:  601/576-6873
 Facsimile:  601/576-6824
 

___
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 print circulation slips

[Liz Rea]

I also added one more bit of information regarding better use of Firefox as a 
Koha client:

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

This way you can have a version of firefox with a restricted printer, and a 
version that can print to any printer.

Liz Rea
NEKLS

On Apr 13, 2011, at 8:57 AM, Linda Culberson wrote:

 What wonderfully detailed information! Thank you!
 Linda
 
 On 4/13/2011 8:47 AM, Liz Rea wrote:
 Linda,
 This configuration information may help you, it is what we do to
 configure our receipt printers to print automatically.
 
 http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/
 
 http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/You
 can also do this with a version of portable firefox, used only for Koha,
 that has the receipt printer configurations built in. I'm happy to
 provide direction in how to get that working as well (there are a few
 tricks to it).
 
 Liz Rea
 NEKLS
 
 On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:
 
 All,
 I am trying to find a way to print circulation slips (hold/checkout)
 automatically. Has anyone else tried to do this?
 Thanks!
 --
 Linda Culberson lcul...@mdah.state.ms.us mailto:lcul...@mdah.state.ms.us
 Archives and Records Services Division
 Ms. Dept. of Archives  History
 P. O. Box 571
 Jackson, MS 39205-0571
 Telephone: 601/576-6873
 Facsimile: 601/576-6824
 
 ___
 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/
 
 
 -- 
 Linda Culberson   lcul...@mdah.state.ms.us
 Archives and Records Services Division
 Ms. Dept. of Archives  History
 P. O. Box 571
 Jackson, MS 39205-0571
 Telephone:  601/576-6873
 Facsimile:  601/576-6824
 

___
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-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN

[Liz Rea]

Then I make a formal proposal that as a community we have an understanding of 
the following guidelines:

For Debian and Ubuntu, we prefer to suggest/use packaged versions (if they are 
adequate) for the latest stable version of the OS at the time of release. Other 
dependencies that do not have packages or the packaged version is inadequate 
can be retrieved from CPAN, and the documentation will note which they are.

Required versions should be the lowest version that allows all Koha 
functionality. It is the responsibility of the person adding an enhanced 
functionality to up the required version number when necessary.

Other OS's are supported with dependencies coming from CPAN or packages/RPM's 
for that distribution, assuming they meet the version requirement.

What do you think?

Liz Rea
NEKLS


On Dec 2, 2010, at 2:09 PM, LAURENT Henri-Damien wrote:

 Le 02/12/2010 17:28, Paul Poulain a écrit :
 Le 02/12/2010 17:25, Chris Nighswonger a écrit :
 I did actually think about this before I did it. :)
 
 I asked around if it would be better to update the documentation to take
 the package out of the install script and add it to the CPAN list, or do
 what I did, and the general consensus was that backing down the required
 version was a better option (since the newer version doesn't add any
 functionality that we actually use), so I did that.
 
 The reason is that a lot of people use Lenny (and or Ubuntu, which would
 cause this same issue), and Squeeze/Sid aren't stable yet (even though they
 work fine, I know that). Every indication I've gotten is that we prefer
 packaged versions of things instead of pulling direct from CPAN. I chose to
 eliminate the error message when installing on Lenny/Ubuntu from
 Makefile.PL, and allow a required version that was lower than the current
 version to help eliminate a bad user experience (An error!!! OMG! What do I
 do!).
 
 you can count BibLibre in we : we prefer packaged versions, no doubts !
 So ++ to your proposition to have the oldest version that works fine
 required !
 
 I agree with that.
 But then we have to be quite specific then about the OS we support
 Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of
 perl module packaging.
 Or should we try and maintain packages for all the versions ?
 -- 
 Henri-Damien LAURENT
 ___
 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/