from:"Martin Renvoize"

Re: [Koha-devel] Centralize and move to gitlab

2018-08-08 Thread Martin Renvoize

Should the contribs repo also be moved/mirrored on gitlab too?

*Martin Renvoize*

Development Team Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvo...@ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at i...@ptfs-europe.com



On Wed, 11 Jul 2018 at 20:47, Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:

> git-bz and kohadevbox have been moved as well!
>
> On Mon, 25 Jun 2018 at 09:43 Renvoize, Martin <
> martin.renvo...@ptfs-europe.com> wrote:
>
>> Well spotted Mark, would be good to get those moved too :)
>>
>> *Martin Renvoize*
>>
>> Development Manager
>>
>>
>>
>>
>> *T:* +44 (0) 1483 378728 <+44%201483%20378728>
>>
>> *F:* +44 (0) 800 756 6384 <+44%20800%20756%206384>
>>
>> *E:* martin.renvo...@ptfs-europe.com
>>
>> www.ptfs-europe.com
>>
>>
>>
>> <https://www.ptfs-europe.com>
>>
>>
>>
>> Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30
>>
>> The information contained in this email message may be privileged,
>> confidential and protected from disclosure. If you are not the intended
>> recipient, any dissemination, distribution or copying is strictly
>> prohibited. If you think that you have received this email message in
>> error, please email the sender at i...@ptfs-europe.com
>>
>>
>> On 23 June 2018 at 03:17, Mark Tompsett  wrote:
>>
>>> Greetings,
>>>
>>> Will gitify and git-bz be moved as well? Kohadevbox is still using the
>>> github of those.
>>>
>>> GPML,
>>> Mark Tompsett
>>>
>>> ___
>>> 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/

Re: [Koha-devel] ILS-DI GetRecords

2018-08-08 Thread Martin Renvoize

I agree, it feels like a bug.  I just had a quick read through ils-di docs
elsewhere and can't see any mention of such information being returned by
that call.

*Martin Renvoize*

Development Team Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvo...@ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at i...@ptfs-europe.com



On Wed, 8 Aug 2018 at 10:47, Katrin Fischer 
wrote:

> Hi jonathan,
>
> I feel like the issue information is too much there and doesn't fit the
> purpose of the command, described as "Given a list of record identifiers,
> returns a list of record objects that contain bibliographic information, as
> well as associated holdings and item information".
>
> Can we track the additonal behaviour back to a bug that added it?
>
> I noticed, that there is an error for a non-existent biblionumber. I feel
> like that might be a regression:
>
> Can't call method "biblioitem" on an undefined value at 
> /home/vagrant/kohaclone/C4/ILSDI/Services.pm line 212
>
> Katrin
>
> On 06.08.2018 22:46, Jonathan Druart wrote:
>
> Hi devs,
>
> I am trying to remove the subroutine GetItemsByBiblioitemnumber, which is
> only used from C4::ILSDI::Services::GetRecords.
> It generates timestampX, cardX and borrowerX for the last 3 patrons who
> checked out the items.
>
> I have no idea if it is a desired effects but, as this code has been there
> for a very long time (2005), I suspect it's not. Could anyone confirm?
> The "doc" (/ilsdi.pl?service=Describe=GetRecords) does not say
> anything about the checkouts info.
>
> Cheers,
> Jonathan
>
>
> ___
> Koha-devel mailing 
> listkoha-de...@lists.koha-community.orghttp://lists.koha-community.org/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/

Re: [Koha-devel] Client-side git hooks

2018-07-20 Thread Martin Renvoize

I use git-hooks pretty extensively though I'm still porting many of them
from the project I've been working on for the last year for use with Koha.

There's so much you can do, for instance, I used to always run
perltidy over any changed files in my commit to ensuring I stayed tidy
(won't be porting that one).

The compile check is a great one too.. perhaps we should share more of
these on the wiki?  There are a few in the release management and
maintenance pages, but there's the scope that we could improve everyone's
coding by suggesting some (I used to also run a perl lint script that would
point out all my bad habbit and ensure I conformed to perl best practices..
it was a great way to learn and improve my perl).

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvo...@ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at i...@ptfs-europe.com



On Fri, 20 Jul 2018 at 09:53, David Cook  wrote:

> Hi all,
>
>
>
> How many of you are using client-side git hooks? That is, git hooks that
> are in your working directory.
>
>
>
> A while ago, I added a “pre-commit” git hook in my Koha git working
> directory, which runs a little Python script every time I make a commit.
> It’s nothing fancy. Basically it gets a list of all the files I’m changing
> in Git and for a “.pl” or a “.pm” file, it runs “perl -c", which compiles
> the Perl code without running it (with a caveat about BEGIN{} blocks which
> do get run at compile time so could be a problem if you’re running
> untrusted code especially as a privileged user…). The Python script gets
> the exit code of that operation, and if there’s an error, it uses an exit
> code of 1 itself and prevents the commit from happening. I’ve attached some
> sample code to the bottom of this email under “__PYTHON_SCRIPT__”.
>
>
>
> I find that it’s a nice way of catching errors. Maybe you write some code
> and you don’t think you need to test it, or you tested it but you made a
> last minute change and that last minute change has a typo… this catches
> that kind of things – at least if it’s an error which prevents successful
> compilation.
>
>
>
> Anyway, I was just porting a patch between different versions of Koha, and
> everything looked good at a glance and the code merge was successful, but
> the commit failed because one variable name in one line of the many lines
> changed was slightly different.
>
>
>
> The error messages told me exactly where to go and then it was obvious
> what the problem was and what to do.
>
>
>
> Anyway, I just thought I’d share that. Maybe everyone is already using
> client-side git hooks, but I thought I’d share just in case someone else
> finds it useful. Especially as it saved my bacon just now.
>
>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>
>
> __PYTHON_SCRIPT__
>
> #!/usr/bin/env python
>
>
>
> import subprocess, os
>
>
>
> errors = 0
>
>
>
> output =
> subprocess.check_output(["git","diff","--cached","--name-only","--diff-filter=ACMR"])
>
> lines = output.split('\n')
>
> for line in lines:
>
> if line:
>
> filename, file_extension = os.path.splitext(line)
>
> print(filename)
>
> print(file_extension)
>
> if file_extension == ".pl" or file_extension == ".pm":
>
> rv = subprocess.call(["perl","-c",line])
>
> if rv:
>
> errors += 1
>
>
>
> if errors > 0:
>
> exit(1)
> ___
> 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] Discussion about internal API design.

2018-07-19 Thread Martin Renvoize

The Koha namespace is already starting to suffer from many of the issues we
encountered within C4, with rather organic growth.

I've been trying to promote some api design discussions in
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11983.

To summarise, rather than adding lots of ->search_for_x, ->search_for_y,
->search_for_z methods to our objects I'd like to come up with some
guidelines on code re-use and method naming conventions. (along with
improving our current perldoc procedure to make the docs more informative
and helpful, but let's cover that in another bug ;) ).

Please take a look at the example code options I've presented in the bug
and chip in with your thoughts, suggestions. Jonathan has already made some
great suggestions and I'd love to see us working towards having clearer
conventions and more code re-use.

Thanks in advance,

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvo...@ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at i...@ptfs-europe.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/

Re: [Koha-devel] Koha users wiki page outdated, use HEA

2018-07-09 Thread Martin Renvoize

Somewhat confused by that comment...

* 1693 unnamed libraries.. I see lots of names here.. am i missing
something: https://hea.koha-community.org/libraries ?
* 35 really up to date.. t's useful to see the distribution of installed
versions.. the HA stats are fed directly from koha installs and as such are
automatically kept up to date. I don't really see what your point was there?
* It's easier to opt in to HEA than it is to manually add yourself to the
wiki pages (if you even know of the existence of the wiki pages)
* Clicking through to the library detail page in HEA shows all the
information and more doesn't it:
https://hea.koha-community.org/libraries/274 - If there's something missing
do feel free to request it's addition.

I would happily agree with Pauls proposed approach myself and I'd love to
see more use of HEA.. perhaps this would act as another little reminder of
HEA's existence and a drive to get more libraries to opt in.

The views expressed here are my own and not the views of the company I work
for.

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvo...@ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at i...@ptfs-europe.com



On Mon, 9 Jul 2018 at 08:54, Michael Kuhn  wrote:

> Hi Paul
>
>  > someone pointed me the https://wiki.koha-community.org/wiki/KohaUsers
>  > page.
>
> Calling this page says: "There is currently no text in this page."
>
> Probably you meant https://wiki.koha-community.org/wiki/Koha_Users and
> pages like https://wiki.koha-community.org/wiki/KohaUsers/Europe
>
>  > 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)
>
> Also in HEA I see there are 1'693 (unnamed) libraries listed, but only
> 35 of the area really up to date (meaning working woith Koha 18.05.00 or
> 18.05.01). Compared to the assumed 15'000 Koha libraries this is only
> 0.2% of all libraries that we can be sure of they are really up to date.
>
>  > 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 (<  > explanations about hea>>)"
>  >   * update the wiki pages to add a big warn on top of each, saying
>  > "this page is outdated, see hea.koha-community.org")
>
> Not all information on this page is outdated - only the untended data is
> outdated. I feel personally responsible for some of the data and can
> affirm this data is not outdated.
>
>  > Any objection ?
>
> HEA however doesn't give the same information as the "Koha_Users" pages
> give. The users page shows
>
> * the country
> * the location
> * library type
> * library name (often with URL to the OPAC, most interesting to me - but
> if it's not there I can search for the OPAC URL in Google using the
> library's name)
> * and more information
>
> to very SPECIFIC libraries - all of which is missing in HEA since
> https://hea.koha-community.org/ gives just numbers numbers numbers but
> at least I can't imagine how to wisely interpret or use them in most
> cases since I am absolutely sure they are not representative. To me
> personally, the only halfway interesting thing about HEA is the page
> about the use of the system preferences
> https://hea.koha-community.org/systempreferences
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Proposal to join the QA team for packaging related bugs

2016-08-14 Thread Martin Renvoize

+1 from me too

On Sun, 14 Aug 2016 2:36 am Kyle Hall,  wrote:

> +1 from me as well!
>
> Kyle
>
>
> 
>
> http://www.kylehall.info
> ByWater Solutions ( http://bywatersolutions.com )
> Meadville Public Library ( http://www.meadvillelibrary.org )
> Crawford County Federated Library System ( http://www.ccfls.org )
>
> On Sat, Aug 13, 2016 at 5:55 PM, Tomas Cohen Arazi 
> wrote:
>
>> +1 for me
>>
>> El sáb., 13 ago. 2016 16:06, Mirko Tietgen 
>> escribió:
>>
>>> Hello everyone,
>>>
>>> part of the idea of nightly packages is to constantly update the
>>> Debian related files that deal with depenencies. I would like to
>>> find and solve possible dependency problems early and minimize the
>>> delay between Koha release and related package release.
>>>
>>> The process to build nightlies is getting more stable now. I have
>>> tested automatic patches to the debian/control file -- that is the
>>> file that contains the package dependencies -- and I think it will
>>> be a helpful tool.
>>>
>>> I have created bugs labelled "Automatic debian/control updates" for
>>> master, stable and unstable, and added Kyle, Frederic and Julian
>>> respectively.
>>>
>>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17084
>>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17108
>>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17111
>>>
>>> The bugs get automatic updates after each nightly build process, as
>>> long as they lead to changes in debian/control. To avoid spamming
>>> the bugs I have changed that now to "send patch only if bug status
>>> is 'Assigned'" (untested :P)
>>>
>>> There is not really anything to test here, besides a manual sanity
>>> check. But it will consume resources to go through the QA process
>>> every single time there is a change. For that reason I propose I
>>> join the QA team for packaging matters, do a signoff on the
>>> automatic patches (as long as they are ok), label them "Passed QA"
>>> and send them over to Kyle, Frederic and Julian so they can be
>>> pushed early.
>>>
>>> Any objections? Comments?
>>>
>>> Cheers,
>>>
>>> Mirko
>>>
>>>
>>> --
>>>
>>> Mirko Tietgen
>>> mi...@abunchofthings.net
>>> http://koha.abunchofthings.net
>>> http://meinkoha.de
>>>
>>>
>>> ___
>>> 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/
>>
>> --
>> Tomás Cohen Arazi
>> Theke Solutions (https://theke.io )
>> ✆ +54 9351 3513384
>> GPG: B2F3C15F
>>
>> ___
>> 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/

Re: [Koha-devel] Proposal of a new development for Marseille hackfest, feedback needed

2014-02-11 Thread Martin Renvoize

We've used piwik on and off on a number of our sites to moderate success
too. It leads to some interesting stats.

I'd be happy to see it in the core along with sysprefs to opt in/out, and
would be interested to see how another company has been using it too.

I had issues with piwik becoming unusably slow so we abandoned it a couple
of years ago, monitoring the project though it appears to have come on
leaps and bounds.

Count me in.
On 11 Feb 2014 17:30, Paul Poulain paul.poul...@biblibre.com wrote:

 Hi koha-devel,

 There are sometimes debates about how and who is using Koha, how it is
 setup, which decision is of general interest.
 I had 2 ideas that could be developed during the hackfest. 2 of BibLibre
 developers are very motivated by the idea, anyone else can join us ;-)

  1st idea : collecting -anonymous- data on staff interface usage
 We sometimes are wondering whether librarians are running an old version
 of IE, or if they have a large screen, or if the page X is often run or
 not.
 There's a tool that could let us know: piwik (BibLibre already has an
 offer on Piwik for the OPAC)
 The idea here would be to add piwik for staff interface, and collect all
 datas on a single piwik instance.
 We made something (quick) for one of our current supported library, just
 to see what kind result we could get. We're quite happy with the
 performances, datas are interesting (which browser is used, which screen
 size, which pages. [ For example, the library runs an average of 40
 times reports/catalogue-stats.pl every day (yes, that's crazy ;-) ).
 This page is worth being optimized !!! ]

 The only caveat we've seen for now is that it can be tricky to have many
 websites pointing to the same piwik database.
 We also are not completely peaceful with having 10 000 librarians
 calling the server. We could face a heavy load...

 But that's worth investigating imo.

 (for those who don't know what is piwik, it's like google analytics, but
 respect your privacy ;-) Ah, and it's a software developed by a frenchy,
 living in new zealand, that has office hosted by catalystNZ afaik)
 If the community likes the idea, we will ask him for any advice on the 2
 caveats we fear.
 [ PS: please avoid starting a troll about piwik collecting anonymous
 data or not because of the IP. Anyway, the feature will be trigger-able
 by the library. ]

  2nd idea : collecting nominative datas.
 We very often face the question how many libraries are using Koha
 So the idea is to have a form that let the library declare itself.
 Library name, type (academic, public,...), country,...
 We could also collect other data, like catalog size, systempreferences
 values to be able to make statistics.

 Example of answers we could get:
  * how many libraries are using Koha in Africa ?
  * What's the average catalog size ? Which library is the largest one ?
  * Is someone/how many libraries are using the insecure mode
 (syspref=insecure set to Yes) ? [ If no, we can drop it ! ]

 Each library could choose to share or not the data (and maybe which
 level of data. One could accept to declare itself  share sysprefs, but
 not appear on nominative listings for example)
 A specific website could be made to display informations, either
 nominative or not.

 Do you like those ideas ?

 PS: BibLibre is of course willing to host piwik and statistics servers.
 --
 Paul POULAIN - BibLibre
 http://www.biblibre.com
 Free  Open Source Softwares for libraries
 Koha, Drupal, Piwik, Jasper

 ___
 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] Wiki page update question

2014-02-10 Thread Martin Renvoize

I do it for you, but I tend to think leading least on is better than just
going ahead and fixing things.

The item your looking at is being included on the page as a template. ( in
fact any inclusion that can be seen as {{pagename}} in the source of a page
is known as a template in mediawiki.  You can find such pages by limiting a
search to the template namespace.  So, your page is at
http://wiki.koha-community.org/wiki/Template:DevBook and it explains how to
modify it there.

If we were more clever we could use semantics to auto include a page in the
devbook depending on its contents using dB like queries.

As a side note, you are not limited to only including templates on pages,
you can in fact include any page on another page using {{namespace:page
name}}.

Hope that helps.
On 10 Feb 2014 06:55, Mark Tompsett mtomp...@hotmail.com wrote:

   Greetings,

 http://wiki.koha-community.org/wiki/Developer_handbook
 Handy little page, but as I have noted on the discussion, the QA Testing
 Tools are missing from the list.

 Who? Where? How? Et cetera, et cetera – do I get the QA Testing Tools onto
 the page?
 That little macro-y {DevBook} is too magical for a wiki newbie like myself.

 GPML,
 Mark Tompsett

 ___
 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] ElasticSearch for Koha - presenting the Koha Gruppo Italiano's project

2014-02-05 Thread Martin Renvoize

It's great to see such an interest in putting ElasticSearch into Koha.

May I suggest you try to catch up with Chris Cormack.. he stated in the
3.16 Architectural Goals mail thread on this list that he was already
working on integrating ElasticSearch (some Catalyst with Bywater
collaboration I believe), visible here:
http://git.catalyst.net.nz/gw?p=koha.git;a=shortlog;h=refs/heads/elastic_search

I'm sure he'll pipe up by himself soon enough.. but it would be terrible to
see duplicated effort.. on the flip side it would be great to see some more
collaboration and funding for the developers to be able to spend more time
on getting this right.

Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Landline: 0203 286 8685
Mobile: 07725985636

http://www.ptfs-europe.com


On 5 February 2014 16:34, Stefano Bargioni bargi...@pusc.it wrote:

 The Koha Gruppo Italiano is proud to present a new project for the
 development of Koha.

 Recently the community has shown a big interest in substituting Zebra with
 a new search engine. How this is done -- whether Zebra is replaced or
 complemented, etc. -- will determine the workload and necessary financial
 support.

 The Koha Gruppo Italiano wants to promote the project through a
 crowd-funding campaign, sponsorships, events, endorsements etc.

 The Koha Gruppo Italiano would like to bring together the community of
 developers to determine the possibility of introducing the new search
 engine, to set up the work flow, and to collect the funding necessary for
 the project. On March 11, 2014 the project will be presented in Marseille
 at the Koha Hackfest for evaluation. Important software editors/producers
 working for Koha, and others interested in the project will be invited. The
 project will be presented by Stefano Bargioni, Deputy Director and System
 Librarian at the Library of the Pontificia Università della Santa Croce.
 The goal is to discuss solutions, and propose ideas in order to take
 initial decisions.

 The project and its progress can be followed through the website 
 http://kohagruppoitaliano.moonfruit.com, on FB 
 http://www.facebook.com/KohaGruppoItaliano and on Twitter 
 https://twitter.com/kohagruppoit.

 We are very interested to hearing your first impressions, your suggestions
 etc. about this proposed project. Please respond to this e-mail if you have
 any comments. Probably the best contributions during this early phase will
 be the definition of the fundamentals. Example:

 - Which search engine? - ElasticSearch, Solr or other (even if, at this
 time, the name of the initial project is ElasticSearch for Koha)?
 - Should the effort focus on complementing Zebra or on its replacement?
 - Subdivide the workload.
 - Draft a road map.

 We are grateful to all developers who will be contributing to our project.
 We hope that this project is seen favorably within the community, and
 specifically wish that the Librarian community worldwide see the benefits
 of this project and would be willing to assist us with finding financial
 support.

 Kindest regards,
 Franziska Wallner, Stefano Bargioni, Sebastian Hierl, Juan Diego Ramirez

 ___
 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] Adding Wysiwyg to (HTML) System Preferences

2014-01-17 Thread Martin Renvoize

I've been thinking of doing something like this for some time, so would
love to see it happen. (and I'm sure our customers would love it)

I was of two minds whether to implement TinyMCE as wysiwyg, or one of the
code editors out there to do syntax highlighting, indenting  and linting
for all code type blocks (css, html, yaml etc), but I think for your
average user the wysiwyg approach is the right one.

Would be happy to test a patch.

Martin

Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Landline: 0203 286 8685
Mobile: 07725985636

http://www.ptfs-europe.com


On 17 January 2014 11:04, MJ Ray m...@phonecoop.coop wrote:

 David Cook wrote:
  What would folks think about adding the tinymce wysiwyg to some of the
  system preferences that deal with HTML?

 I think it would probably be a useful feature to many libraries and
 tinymce seems like the best of the current rather weak bunch.

 A system preference to control it seems like a good thing.

 If you can make tinymce abort if it finds handcoded html that it can't
 preserve (I don't know if this is possible), then that would be great.

 Hope that helps,
 --
 MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op
 http://koha-community.org supporter, web and library systems developer.
 In My Opinion Only: see http://mjr.towers.org.uk/email.html
 Available for hire (including development) at http://www.software.coop/
 ___
 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

2013-12-11 Thread Martin Renvoize

On the ElasticSearch front, is there an RFC somewhere with some really
clear technical goals for the development stating what problems it hopes to
solve and how..?  I'de like to see these so the project gets as much
support as possible as I'de love to see it flourish to completion.  I'm
wondering if zebra should always continue for z3950/SRU as it's good at
that, and we should never intend on using ElasticSearch (which is much more
about keyword searching) for it?

Either way, I want to add my thanks for Brendan and Chris for getting this
move going.. if I can help at all with any of it give me a shout..




Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Landline: 0203 286 8685
Mobile: 07725985636

http://www.ptfs-europe.com


On 11 December 2013 11:27, Mathieu Saby mathieu.s...@univ-rennes2.frwrote:

  I was just asking questions...
 Some answers are here
 http://gs.statcounter.com/

 France:
 Firefox 2.00.02
 Firefox 3.00.06
 Firefox 3.50.05
 Firefox 3.60.28
 IE 6.00.13
 IE 7.00.94
 = total = 1.48% last month

 Philippines:
 Firefox 2.00.01
 Firefox 3.00.05
 Firefox 3.50.05
 Firefox 3.60.62
 IE 6.00.12
 IE 7.00.72
 = total = 1.57% last month.

 Nigeria:
 Firefox 2.00.07
 Firefox 3.00.81
 Firefox 3.50.14
 Firefox 3.61.02
 IE 6.00.12
 IE 7.00.2
 = total = 2.18% last month

 Afghanistan
 Firefox 2.00.04
 Firefox 3.00.2
 Firefox 3.10.01
 Firefox 3.50.22
 Firefox 3.60.51
 IE 6.00.1
 IE 7.00.28
 = total = 1.28% last month

 Algeria:
 IE 6.00.2
 IE 7.00.39
 Firefox 2.00.07
 Firefox 3.01.01
 Firefox 3.50.31
 Firefox 3.61.47
 = total = 3.27% last month

 And these figures will be even lower in 6 monthes
 So If the data are correct, I suppose you are right, and support for those
 browsers could be safley dropped.

 Mathieu




 Le 11/12/2013 11:33, Chris Cormack a écrit :

 * Mathieu Saby (mathieu.s...@univ-rennes2.fr) wrote:

  Hi
 Do you know what is the share of FF 3.6 and IE 7 in Nigeria,
 Philippines, Pakistan or Turkey?
 I suppose that people in those countries probably can't afford to
 change computers as soon as here...

 By the way, my university is still using Windows XP, so it is not
 dangerous (but of course we plan to change OS in 2014)
 And 1 year ago, the FF standard version insalled on staff computers
 was 3.6! (Now it is 10 or 17, I don't remember)
 From what I understood (that's not my part ;-) ), using fresher
 version of FF was not an easy task for our IT department, because FF
 was virtualized, and the older versions are somehow lighter than
 the recent ones.


  You're right, lets give it another 7 years before we upgrade (october
 2006 it was released).

 Chris

 PS I wrote this using ae on my machine running linux 1.0.


  Mathieu


 Le 11/12/2013 02:56, Paul A a écrit :

  At 09:59 AM 12/11/2013 +1300, Liz Rea wrote:


  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.)

  Mine too (and we're small so maybe near the bottom end of the
 relevancy scale.)


  IE 7 is only available in Windows XP, which is due to be end of life in
 April 2014.

  First, I really have no opinion on IE 7 thru 10 -- I do read the
 stats on market share, and I do have access (for webpage
 verification purposes) of IE8, but that's it...


  Any changes we make for this cycle won't be released until
 after XP is EOL. [snip] XP is an outdated, and dangerous
 operating system to be
 running.

  We're all entitled to our opinions and I respect yours. However
 XPPro SP2,[1] properly set up (with a *user* account, never go
 on-line with admin privileges) is not dangerous.  EOL, maybe,
 but I feel that Koha is gaining ground in (excuse me if I'm not
 PC) less developed countries where quite frankly older o/s abound
 for whatever reasons.

 Upgrading Koha to deny XP (and I'm not at all sure that's what's
 being proposed) might be cutting off our noses to spite our face.


  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.

  For the record, I still have (no time to rebuild) half a dozen
 kiosks that run FF3.6 under Win98SE (despite a whole bunch of
 misinformation that it's not possible) -- the Koha OPAC is
 visually perfect (3.8.5 near standard OPAC CSS) and very fast.
 YMMV.

 Bottom

Re: [Koha-devel] Roundtable on SAX Parser settings.

2013-11-06 Thread Martin Renvoize

Great news on all this..

Just wanted to thank Robin for stepping up to the plate so quickly to get
it in his repository after the discussion too.

On 5 Nov 2013 23:15, Robin Sheat ro...@catalyst.net.nz wrote:

 Robin Sheat schreef op wo 06-11-2013 om 11:31 [+1300]:
  it might just be that my build environment needs to be upgraded, I'll
  have a look at that today hopefully.

 It was, and I did, and it worked. MARC::File::XML 1.0.1 is now in the
 repo.

 --
 Robin Sheat
 Catalyst IT Ltd.
 ✆ +64 4 803 2204
 GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF

 ___
 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] OPAC theme proposal

2013-10-28 Thread Martin Renvoize

+1...
On 28 Oct 2013 20:26, Doug Kingston d...@randomnotes.org wrote:

 +1 on the strategy.


 On Mon, Oct 28, 2013 at 11:34 AM, Owen Leonard oleon...@myacpl.orgwrote:

 +1 from me on the timeline.

  [4] The RM will assist in getting OPAC template patches in the pipeline
 that
  were written for prog updated to support Bootstrap as well.

 I'm happy to help too.

   -- Owen

 --
 Web Developer
 Athens County Public Libraries
 http://www.myacpl.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/

Re: [Koha-devel] Hackfest update #1

2013-10-21 Thread Martin Renvoize

I'll back that up, the facets Jared demonstrated certainly were pretty in
all their diacritics glory :-)
On 21 Oct 2013 05:41, Mathieu Saby mathieu.s...@univ-rennes2.fr wrote:

 **
 Great news!


 Jared Camins-Esakov a écrit :

 Mathieu,

  I read in old messages of Zebra list (msg from Henri Damien Laurent and
 other Koha dev), whose general thrust was that Zebra built-in facets were
 not working well for strings with diacritics, or maybe with ICU.

 https://www.google.fr/search?q=facets+zebra+icu+site:lists.indexdata.dkclient=firefox-ahs=9nqrls=org.mozilla:fr:officialchannel=fflb
 Is it still true?


  No. I demonstrated that it works fine now. I used ICU and a search for
 German records returned facets with properly encoded umlauts. The changes
 that you note in 2.0.34 may be what makes it work, but I'm actually not
 sure that we didn't just always have Zebra configured incorrectly, using
 tokenized indexes rather than untokenized indexes.

  Regards,
 Jared

  --
 Jared Camins-Esakov
 Bibliographer, C  P Bibliography Services, LLC
 (phone) +1 (917) 727-3445
 (e-mail) jcam...@cpbibliography.com
 (web) http://www.cpbibliography.com/



 --
 Mathieu Saby
 Service d'Informatique Documentaire
 Service Commun de la Documentation
 Université Rennes 2
 Téléphone : 02 99 14 12 65
 Courriel : mathieu.s...@univ-rennes2.fr


 ___
 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] Linking bibs to authorities

2013-10-17 Thread Martin Renvoize

Hi Galen,

The patch in question that Ian mentions regarding adding phrases config to
zebra for dom with icu.. which also heavily affects the authority linking
results that he is talking about is under bug: 10729.

I'm just about to update the bug with a description so it can be seen the
two things relate.. The patch affects more than just the authorities
linking script, but I believe using the linking script is possibly the
easiest way to show that the patch is actually doing somthing.

Just chipping in,

Martin
On 17 Oct 2013 10:17, Galen Charlton g...@esilibrary.com wrote:

 Hi,

 On Thu, Oct 17, 2013 at 9:35 AM, Colin Campbell 
 colin.campb...@ptfs-europe.com wrote:

 Just an vague idea but I wonder if using zebra (or similar search
  utilities) for authorities is really a good idea. They are great for
 general bib search where you want to find more, even unexpected results.
 But with authorities your concern is to find a specific record as such
 the search facilities in a standard db are probably more useful. Just
 because a tool works well in one context it does not mean its the best
 in another (pick your favourite hammers  scredrivers analogy)


 Well, the original motivation for implementing the Zebra DOM filter for
 MARC21 authority records was to enable the construction of normalized index
 strings for authority headings that included details such as the thesaurus
 for subject headings, thereby allowing precise matching that went beyond
 just the equivalent of keyword searches.

 Of course, the equivalent could be done in a database, but I think it
 would be fruitful to first properly investigate the bug.

 To that end, I request that a bug report actually be filed -- I see
 nothing apropos on Bugzilla -- preferably with sample records.

 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] Patron Attributes with Password?

2013-08-01 Thread Martin Renvoize

I've just been taking a look at the manual again (
http://manual.koha-community.org/3.12/en/patscirc.html#patronattributetypes)
and I'm not really understanding what the 'Allow password: Check to make it
possible to associate a password with this attribute.' option is actually
meant to do when creating a new patron attribute type?

I thought it would allow the creation of additional login
(username:password) combinations for a user to login to the opac but it
doesn't appear to do this (if it was meant to, surely it would need to only
be available when the attribute is also set to be unique).

Anywho, if that is it's purpose, then I'll report a bug, but if it's not
the purpose could anyone explain what is was meant to do?

-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Landline: 0203 286 8685
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] Koha.next: Consolidate OPAC themes?

2013-04-15 Thread Martin Renvoize

I like the idea of merging the two themes, along with moving towards a
nicer includes/block scheme for opac elements.

Using the css and javascript preferences are a great way to do your
individual customisations, and the more blocked the system becomes the
simpler it will be to use css/javascript to override placement of each
individual item on a page.

It would be good to see the 'theme' sys prefs disappear altogether
eventually if we're moving to using the css/javascript overrides as the
theme customisers of choice.

My two cents,

Martin


On 13 April 2013 13:03, Kyle Hall kyle.m.h...@gmail.com wrote:

 +1 agreed! Don't know what I was thinking!

 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 Fri, Apr 12, 2013 at 5:59 PM, Owen Leonard oleon...@myacpl.org wrote:

 On Fri, Apr 12, 2013 at 5:45 PM, Kyle Hall kyle.m.h...@gmail.com wrote:
  Essentially, because it support mobile devices better than prog.

 But this whole discussion is about merging CCSR and prog! We don't
 have to pick one if we make one that is the best of both!

   -- Owen

 --
 Web Developer
 Athens County Public Libraries
 http://www.myacpl.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/




-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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] Question about SRU responces

2013-02-13 Thread Martin Renvoize

Hi All,

We've recently been updating a number of customers to using DOM indexing
and mostly it's going well.  However, I just wanted to clarify something
about the Z39.50/SRU server.

The responce given from old chr based zebra and dom based zebra is in a
completely different format. Is this correct, or is it a bug?

I've attached a couple of examples to show the difference?

 
biblios_chr.xmlhttps://docs.google.com/a/ptfs-europe.com/file/d/0B27FAnukSs76SFJ3NEFlLURTYUU/edit

 
biblios_dom.xmlhttps://docs.google.com/a/ptfs-europe.com/file/d/0B27FAnukSs76N25oaFVFZWxuaUU/edit


-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] Question about SRU responces

2013-02-13 Thread Martin Renvoize

Ooops..

Didn't mean to attach those docs in that way..

It's probably easier if I just link to the two public sru servers I used to
get the example files. (and yes Jared, your right.. I didn't mean chr vs
icu.. i meant grs-1.. too many tla's)

With GRS-1:
http://bldscat.ids.ac.uk:9998/biblios?version=1.1operation=searchRetrieverecordPacking=xmlquery=any=medicalstartRecord=1maximumRecords=1

With DOM:
http://tavi.koha-ptfs.eu:9998/biblios?version=1.1operation=searchRetrieverecordPacking=xmlquery=any=medicalstartRecord=1maximumRecords=1

Cheers

On 13 February 2013 15:17, Jared Camins-Esakov
jcam...@cpbibliography.comwrote:

Martin,

We've recently been updating a number of customers to using DOM indexing
and mostly it's going well. However, I just wanted to clarify something
about the Z39.50/SRU server.

The responce given from old chr based zebra and dom based zebra is in a
completely different format. Is this correct, or is it a bug?

You can use DOM + chr if you like. Just choose chr instead of icu when
running the installer. However, if ICU changes the format, then, yes,
that's a bug, probably with Zebra.

It just occurred to me you might mean GRS-1 rather than chr. If that's the
case, then I suspect it probably is a bug, probably an incorrect stylesheet
path in koha-conf.xml or the like.

I've attached a couple of examples to show the difference?

Could you please upload the files somewhere we can access them without a
password?

Regards,
Jared

--
Jared Camins-Esakov
Bibliographer, C P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcam...@cpbibliography.com
(web) http://www.cpbibliography.com/

--
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] Amazon Cover Images

2013-02-07 Thread Martin Renvoize

I agree Chris,

I'de like to see this either stay client side, or have the URL's cached
within koha's DB server side.  I don't much like the idea of having to run
a further server/service.

Martin


On 7 February 2013 10:42, Chris Cormack chr...@catalyst.net.nz wrote:


 * Frédéric Demians (frede...@tamil.fr) wrote:
  I've played with this idea of a cover images centralized cache of URLs.
  I have a mock-up. Anybody interested in testing, commenting?
 
  Client side (Koha), two syspref enable the service. URL are fetched from
  the cache, via JSONP, just Google Books:
 
 
 http://git.tamil.fr/?p=koha;a=commitdiff;h=e8e223437a5f61c8320cba1b9563a2eb81a6f9f2
 
  Server side, it's a node.js + redis small application:
 
 
 http://git.tamil.fr/?p=coce;a=commitdiff;h=5e8021a95df07c7a5b14692955ac4c23c7490990
 
  It works now with Amazon and Google Books, but can be extended easily to
  support other providers. It could work with other ILS than Koha. I can
  show how it works on a Koha devel instance.

 I was thinking we could do it all client side with js and html5 (and
 localstorage or indexdb) You'd define the order in system preferences,
 local, google, amazon, ltfl etc. Then the js would try them in that
 order and cache the resulting url (or the fact it couldn't find one)
 in localstorage or indexdb, which persists even when the browser is
 closed.

 That way it wouldnt need to be another server/service, since you have
 the js already, it shouldn't be too hard to convert it to an html5
 client side app.

 Thoughts?

 Chris

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

 --
 Chris Cormack
 Catalyst IT Ltd.
 +64 4 803 2238
 PO Box 11-053, Manners St, Wellington 6142, New Zealand

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




-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

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

2013-01-07 Thread Martin Renvoize

Hi Quoc Uy,

I've got a feeling your misunderstanding the virtual hosts set-up that
Jonathan and Liz are talking about.  In the setup described you are using
one koha install with on database and one staff client.  The big difference
is that your using multiple OPAC's for that single koha instance so you can
give each library their own opac style.

So you end up with a custom opac with it's own unique url for each branch.
 I don't believe the functionality your looking for to change the styling
only upon login on one url currently exists.

Martin


On 5 January 2013 13:08, Quoc Uy nguyenquocuy_1...@yahoo.com wrote:

 To Liz and Jonathan: What you two said is similar:
 http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC
 I'm not sure about what you are talking is about independent branches or
 separated instances. Now we can create a lot of instances with only one
 Koha installation, each instance has its own database, URL (opac and
 intranet), and of course they have their own CSS, HTML templates. But it's
 not what i mean.
 Branches use only 1 shared database, and all user only need to access to
 only one URL, and only when they login, they will see different interfaces,
 based on branch library they registered. If we have only 1 databases for
 100 branches, it's easy for us to maintenance, manage, control system
 preferences. It goes with SYS.Pref Independent branches turn to ON.
 Sorry for any miss-understanding.
 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/




-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] Upgrading Koha's license?

2012-11-15 Thread Martin Renvoize

+1 for GPL3.

Also, I've been prototyping a new theme written from scratch using Zurb
Foundation (MIT License) as a framework (and SCSS as a css
pre-processor), admittedly it's not got much beyond the opac-main page yet.
 I'de be interested to see how your Bootstrap work compares to the
Foundation alternative Owen.

Martin

On 15 November 2012 07:00, Magnus Enger mag...@enger.priv.no wrote:

 On 14 November 2012 22:35, BWS Johnson abesottedphoe...@yahoo.com wrote:
  I'd say simple majority at an IRC meeting with this advertised on
 the agenda so it doesn't sneak up and bite anyone.

 I have added it to the agenda:
 http://wiki.koha-community.org/wiki/General_IRC_meeting,_5_December_2012

 Best regards,
 Magnus
 ___
 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/




-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] Koha and MariaDB - lets switch and start testing

2012-11-12 Thread Martin Renvoize

Any sources as to the MySQL going to explode soon statement?  I'm
probably behind the times, but I hadn't heard such rumours yet?

On 12 November 2012 03:12, Chris Nighswonger
cnighswon...@foundations.eduwrote:

 On Sun, Nov 11, 2012 at 6:59 PM, Mason James m...@kohaaloha.com wrote:
  hi Folks
 
  i am just sending out an email to encourage Koha developers to switch to
 MariaDB for their Koha dev/testing/QA work
 

 I've been singing this tune for awhile and am still all for it. :-)

  fyi: 6 weeks ago, i switched to MariaDB for my dev and QA work, so far -
 ZERO problems :)

 There are a couple of gotchas as MariaDB's sql seems to be a bit
 stricter in some places. I'll try to remember to have a look tomorrow
 at my old dev repo which I ran over MariaDB for about a year. I think
 I have some patches for the areas I found. Nothing major, though.

  time passes 

 I found them and attached them to the bug we opened for this very long ago:

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

 They may or may not apply at this point, but should at least indicate
 where I found issues.

 Kind Regards,
 Chris
 ___
 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/




-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] RSS and SMS overdues cronjob

2012-11-05 Thread Martin Renvoize

We have a number of customers using the rss feeds script, though none using
the sms script.  It's probably something that should be updated to use
template toolkit as well to prevent the extra dependency. (It's been on my
tto do list for a while now, but i've not yet had a chance to do it.)

Martin

On 2 November 2012 13:19, Jared Camins-Esakov jcam...@cpbibliography.comwrote:

 Nicole,

 I don't know anyone using SMS, but the SMS script links to a sys pref
 that lets you turn it on - I don't know if you want to remove that.
 Also the RSS one allows for custom RSS feeds doesn't it? I have it
 documented in the manual, it's optional, but I don't see a reason to
 remove it if it works for some people.


 If it works for some people, then we will need to add HTML::Template::Pro
 back as a dependency of Koha, at least. Which is fine, but is something
 that we should probably know before we ship a major version of Koha with
 non-functioning features. However, I have no idea whether the scripts
 actually work, or whether they've been replaced by modern functionality, or
 what.

 Regards,
 Jared

 --
 Jared Camins-Esakov
 Bibliographer, C  P Bibliography Services, LLC
 (phone) +1 (917) 727-3445
 (e-mail) 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/




-- 
Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Mobile: 07725985636

http://www.ptfs-europe.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/

Re: [Koha-devel] OPAC themes

2012-10-05 Thread Martin Renvoize

I'm not so sure about switching to bootstrap.. it's not as backwards
compatible as jQuery UI for older browsers... but it's an idea.

I would be tempted to use a css framwork though.. (may most of the
advatnages can come from using more features of template toolkit though..
someone stpe in and correct me if thats true).

SASS and LESS are both good css framework options.. giving you more
programatic type options within your style.

Another 2 cents for the pile ;)

On 5 October 2012 07:51, Julian Maurice julian.maur...@biblibre.com wrote:

Le 04/10/2012 21:51, Owen Leonard a écrit :

The new CCSR theme which will be included in 3.10 demonstrates how a
theme can be made responsive, so that the design and layout of a page
can change depending on the device width.

I think the default Koha OPAC should use this technique too.

Making this kind of change gives us the opportunity to make other
changes too, and I'd love to hear from others about what changes those
might be, whether they be ideas about the design, layout, or
structure. Some ideas off the top of my head:

- Use the Bootstrap framework both for the responsive CSS grid and for
the interface widgets (buttons, menus, etc)--but not be slavish to the
default Bootstrap design.
- Use consistent indentation rules on all templates
- Move JavaScript to the bottom of the page (recommended for efficiency)
- Address the needs of people who want to do customization via CSS and
JavaScript. To that end I'd love to hear from the people who are doing
customizations for libraries about their paint points--what aspects of
the OPAC are difficult to change.

I'd like to start working on this, but I think to do it right I think
we need some shared goals.

-- Owen

- Use BLOCK, PROCESS and WRAPPER Template::Toolkit directives everywhere.
I think this could greatly reduces the size of template files and make
writing of templates much easier.

My 2 cents.

--
Julian Maurice julian.maur...@biblibre.com
BibLibre

__**_
Koha-devel mailing list
koha-de...@lists.koha-**community.orgKoha-devel@lists.koha-community.org
http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-develhttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.**org/ http://bugs.koha-community.org/