Re: [Koha-devel] Koha Plugin Hooks documentation

[Eric Bégin]

Thanks for this update Frido !

We are planning to use hooks to interact with external systems on patron 
modifications.


Basically, here what we are planning to implement :

 * Send updates to an external system when patron information is changed.
 * Let the external system know when restrictions change on a patron
   account.

Does anybody feels that could be useful ?

Any heads-upon the implementation ?

I just create this bugizlla : 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27066


Thanks,

Eric

Le 2020-11-20 à 09 h 43, Fridolin SOMERS a écrit :

Hi,

I've worked on :
https://wiki.koha-community.org/wiki/Koha_Plugin_Hooks

Should be update with current hooks in master, and a few under 
development.


Please update this page when developing/integrating a new hook.

Best regards.

___
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] [Koha] Elasticsearch recent works at BibLibre

[Eric Bégin]

Hello Claire,

Bouzid at inLibro worked on some of those issues.

Do not hesitated to contact him (he speak French).

You can get its email on Bugzilla.

Cheers,

Eric Bégin
Solutions inLibro inc.

Le 20-01-31 à 11 h 25, Claire Hernandez a écrit :


Hi,

This week, some devs work together to move forward concretely on 
Elasticsearch issues encountered. You will find below a focus on some 
points (some are at poc state today) written by Alex and Jajm from 
BibLibre. We would be glad to discuss these topics at hackfest in 
march and having user feedbacks too :)


#1 Proof of concept for language analyzers

bug 21357 - 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21357#c32
It's an attempt at having a default ES configuration with stemming, 
elision, etc. that works with multi-languages catalogs

You can read the comments and patch for more information.

#2 Compatibilites for tomorrow

Compatibility with latest version of Search::Elasticsearch - 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24552


Compatibility with Elasticsearch 7.x : Problem: Search::Elasticsearch 
is not yet compatible with ES 7.x, so we are stuck with

 ES 6.x (unless we use something else...)

#3 Querying Elasticsearch in a better way

POC query_string => boolean query 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24555
This POC is about replacing the use of full text queries 
(query_string) with Boolean queries for biblio search


Advantage:
=> No search craches with special character ( "!", ")" etc...)
=> Separate query context and filter context:
- Search scores are not altered by facets,
- Ability to use range filter  (i.e for publication date facet)

Regards,
Claire.








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


--
Eric Bégin

Tél.  : 833-465-4276, poste 200
eric.be...@inlibro.com <mailto:eric.be...@inlibro.com>

INLiBRO | Spécialistes en technologies documentaires | www.inLibro.com 
<http://www.inLibro.com>
___
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] KohaCon18 Portland, Oregon Air Quality

[Eric Bégin]

I'm sure Kohacon will bring a breath of fresh air :-)

⁣Eric Bégin
Solutions inLibro inc.​

Le 22 août 2018 à 21:35, à 21:35, David Cook  a écrit:
>Hi all,
>
>
>
>I don't know why it's just occurred to me to mention it now, but with
>Kohacon coming up quite soon, it's worth keeping an eye on the air
>quality
>and planning ahead:
>https://airnow.gov/index.cfm?action=airnow.local_city
><https://airnow.gov/index.cfm?action=airnow.local_city&cityid=160>
>&cityid=160.
>
>
>
>At the moment, it's rated as "Unhealthy" with a health message of
>"Health
>Message: People with heart or lung disease, older adults, and children
>should avoid prolonged or heavy exertion. Everyone else should reduce
>prolonged or heavy exertion."
>
>
>
>Here's hoping that the air quality improves in the next couple of
>weeks. I
>think the air quality has been bad for a couple of weeks now already,
>but
>again Brendan would have the best info about this.
>
>
>
>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/

Re: [Koha-devel] Koha with Zebra 2.10

[Eric Bégin]

Merci Fridolin and Thanks David :-)

I did use the 2.1 version and didn't see any problem so far, so I'll 
stick with it until a problem surfaces.


By the way, just to let you know, I install it along side Koha on a 
RedHat 7.3 server :-)


Cheers,

Eric Bégin
Solutions inLibro inc

On 17-07-24 08:25 AM, Fridolin SOMERS wrote:

Yep we use 2.1 from indexdata repository, on Ubuntu Xenial.
Works fine.
We think it fixes a bug of server falling without warning.

Regards,

Le 09/07/2017 à 17:04, Eric Bégin a écrit :

Hi everyone,

Zebra 2.1 was released last April.

Anyone tried it with Koha ?  I remember that we encounter some 
problems using 2.0.61 version of Zebra and we had to backtrack to 
2.0.59 before moving to 2.62.


Regards,

Eric Bégin
Solutions inLibro inc.



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





--
Eric Bégin

Tél.  : 888 604-2627
Cell. : 514 777-6572
eric.be...@inlibro.com <mailto:eric.be...@inlibro.com>

inLibro | Spécialistes en technologies documentaires | www.inLibro.com 
<http://www.inLibro.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] Koha with Zebra 2.10

[Eric Bégin]

Hi everyone,

Zebra 2.1 was released last April.

Anyone tried it with Koha ?  I remember that we encounter some problems 
using 2.0.61 version of Zebra and we had to backtrack to 2.0.59 before 
moving to 2.62.


Regards,

Eric Bégin
Solutions inLibro inc.
___
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] Sending email on behalf of customers

[Eric Bégin]

Hi Magnus,

We had this issue too and the way to solve it is that your customer's 
server must "announced" that your Koha server can send email it their 
behalf.


There is usually 2 ways to do so (you must do both)

*SPF - Sender Policy Framework*

*DKIM - DomainKeys Identified Mail*

Digital Ocean has a good guide on how to do this : 
https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy


If you need additional help, Charles, on our team, is the one to contact ;-)

Eric

On 2017-02-13 07:23, Magnus Enger wrote:

Thanks Marcel!

I'll definitely give this a try!

On 13 February 2017 at 11:44, Marcel de Rooy  wrote:

As a workaround: Use real library email address in ReplyToDefault and 
ReturnpathDefault.
Use the real server domain in the From address like library@[yourserver]

My server is available at something like myserver.libriotech.no.
Should KohaAdminEmailAddress (which is used for From by default) be
libr...@myserver.libriotech.no or just libr...@libriotech.no?

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/



___
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] RE : Error on Koha Dev Git install

[Eric Bégin]

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

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

Anyone seen this before and have a solution?  It’s some kind of Apache 
permissions issue, but I’m not sure where. I gave the directory 755 and 
www-data permisions.. ForbiddenYou don't have permission to access / on this 
server.Additionally, a 404 Not Found error was encountered while trying to use 
an ErrorDocument to handle the request.Apache/2.4.10 (Debian) Server at 
xxx.xx.x.xxx Port 8080  I am following these installation instructions… 
https://wiki.koha-community.org/wiki/Install_and_Setup_Koha_to_use_Git_on_a_Development_Server
 thanks, Sincerely,  Scott KushnerSystems LibrarianMiddletown Public Library55 
New Monmouth RdMiddletown, NJ 07748 ___
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] How do we find consensus on interface changes?

[Eric Bégin]

I would rather have a Interface guideline the same way we have coding 
guidelines.


I'm pretty sure that there are some UX design patterns available somewhere.

If we would like to have a rules, I would suggest that something that 
changes the screenshot used in the user documentation should be 
approved, especially when it doesn't add features.


Eric

On 2016-05-31 15:49, Kyle Hall wrote:


I'm concerned that we are going down a road where every patch 
submitted to the Koha project will end up requiring a community vote. 
I think it would be more reasonable and efficient to add a community 
UI manager role to the project. Someone who is empowered to make 
executive decisions on this matter. Either that or accept that the way 
team rules on this matter. The community votes them in after all!


Kyle

Sent from my phone. Please excuse my brevity.

On May 31, 2016 3:32 PM, "Christopher Davis" > wrote:


Owen,

I think that Koha users should voice their opinion/votes as that the
Koha software, more or less, belongs to them. Now, what vehicle should
we use to collect everyone's opinion/vote (like Survey Monkey, Google
forms, IRC voting, etc.) and should there be a committee formed for
this purpose? Maybe decisions such as this one should be voted on
during Koha Devl IRC meetings?

My $0.02 worth,

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

instagram.com/uintahcountylibrary



On Tue, May 31, 2016 at 1:01 PM, Owen Leonard mailto:oleon...@myacpl.org>> wrote:
>> Could the new features which you are proposing be optional?
>
> They're not really new features, they're just changes to the way
> existing features look. We can't build options for every change we
> want to make to the interface. We need to make educated choices
about
> what we think is the best way for things to work. We may not always
> get it right, but it's our job to make the choice.
>
>   -- 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/


___
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] Accidental ban from bugzilla

[Eric Bégin]

Hey Mark,

Here is the goal of our service / script (whatever we want to call it).

The script will go through all bugs with one of those statuses : New, 
Needs Signoff, Signed Off and In Discussion


The script will try to apply the patch on the master.  If the patch 
doesn't apply, it will update its status to Patch doesn't apply.


We believe that too many time, someone is motivated to tests a bug and 
stopped simply because he/she can not apply the patch on the master branch.


This way, this motivated person will have less chance to face this 
situation.


We'll come back later with some figures about how long it takes to 
process the all bugs with those statuses.


Suggestions / ideas for this script are welcome.

Cheers,

Eric Bégin,
Solutions inLibro inc.

On 2016-03-04 11:10, Mark Tompsett wrote:

Greetings,

Why is such a script needed?
For example: 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8587

There was a bot. Is there a reason the bot was discontinued?
Is it broken now?

GPML,
Mark Tompsett


-Original Message- From: Remi MP Sent: Friday, March 04, 2016 
10:53 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] 
Accidental ban from bugzilla

Hi,

Here at inLibro we are developping a perl script that will allow us to 
automatically test bugs for conflicts when their statuses are "New", 
"Needs Signoff","Signed Off" and also "In Discussion". The script will 
change the bugs' statuses to "patch doesn't apply" and notify the 
people involved.


My issue right now is that when I started testing my put requests on a 
bug I created on my own, my account got banned until 15:30 this 
afternoon because of too many login attempts :


Your IP (127.0.0.1) has been locked out of this account until 
2016-03-04 15:28 UTC, as you have exceeded the maximum number of login 
attempts.


Is there a way I could get unbanned? I will install bugzilla locally 
to continue testing, but still I need to be able to access bugzilla 
today.


Thank you!
___
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/

[Koha-devel] RE : Re: Country-specific forks?

[Eric Bégin]

I think we wouldn't have a discussion about 'country-specific' if the patch was 
nor refering Norwegian in its name :)
I believe this bring a much larger topic about plugins.  We are loosing some 
important CPU processing the way stuff are currently implemented.
For example, the code is filled with checks if we are using 
MARC21/UNIMARC/NORMARC.  I think we (the community) would benefit for a more 
modular approach.
The I see this is that we have hooks in the code on which modules (or plugins) 
are registering to be called.  See this as an interface / implementation.  If 
I'm using MARC21, the MARC21 module implements the required interface.
My 0.02 CAD ; )
Eric BéginSolutions inLibro inc.

 Message d'origine 
De : viktor.sa...@regionhalland.se 
Date : 12/02/2016  02:28  (GMT-05:00) 
À : mag...@enger.priv.no 
Cc : koha-devel@lists.koha-community.org 
Objet : Re: [Koha-devel] Country-specific forks? 

I actually think a more general plugin system would both increase the 
attraction of new libraries and keep existing ones from wanting to fork. Being 
a firm believer in running the community code it is sometimes frustrating that 
key features might take years to ge into master. All ways that makes it easy to 
run standard Koha while still altering the behaviour is therefore welcome. 

(At the same time I'm a little bit afraid of a future where the ones with 
resources make their own addons since it's easier and the community codebase 
never gets the chance to implement good features in a generic way. A bit like 
"yes it's not very good, but that's why you'll also want to buy this extra 
discovery system that we happen to sell as well" that seems to happen in some 
proprietary products.)

Kind regards/ Viktor Sarge
Senior regional library development officer 

Skickat från min iPhone

> 11 feb. 2016 kl. 10:38 skrev Magnus Enger :
> 
> Dear Community!
> 
> A quote from another thread on koha-devel:
> 
> "I look at the code, and beside wondering why that custom feature
> [Norwegian patron DB] is so profoundly imbricated into master Koha, I
> was wondering what is not working."
> 
> I think this raises an interesting question. Should we let features
> into Koha that are only of interest to libraries in one or a small
> number of countries? Or should we confine those features to
> country-specific forks?
> 
> The quote above implies (I think) that support for the Norwegian
> patron DB should be in a country-specific fork.
> 
> On the other hand, the project implementing Koha for public libraries
> in Turkey has been criticized for not integrating their customizations
> into Koha. To which someone replied that the customizations were not
> of much interest to libraries outside Turkey.
> 
> So do we want one Koha to rule them all, including country-specific
> features, or do we want one fork per country?
> 
> Personally, I prefer the former. In the case of the Norwegian patron
> DB, that is one of the 2-3 "must have" features that all Norwegian
> public libraries will be looking for when they are choosing between
> Koha or some proprietary system. Should we be telling them "Nope, you
> can't use the real Koha, but you can use this fork over here"? That
> will not increase their confidence in choosing Koha, I suspect.
> 
> That said, I do think some principles should be applied:
> 
> - Strive to make even the country specific features as general as
> possible, so that others can use them as starting points for similar
> features.
> 
> - Strive to make the features as unobtrusive as possible.
> 
> And maybe, in time, the plugin system can be made powerful enough that
> it can handle some or all of the country-specific features?
> 
> Thoughts?
> 
> Best regards,
> Magnus Enger
> Libriotech
> ___
> 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] New RESTful API

[Eric Bégin]

Great work everyone with those specifications !

I think developers would like to be able to expands the API using plug-ins.

What do you think ?

Cheers,

Eric Bégin
Solutions inLibro inc.


On 2015-03-19 23:24, Brendan Gallagher wrote:
Any further comments on the New RESTful API stuff?  We are moving 
forward with that.  We should have some work from Biblibre in the next 
few days (7~10) max.  I'd be interested in knowing who would like to 
help test this all?


Cheers,
Brendan

On Tue, Mar 10, 2015 at 1:40 PM, Chris Cormack <mailto:chr...@catalyst.net.nz>> wrote:


* Tomas Cohen Arazi (tomasco...@gmail.com
<mailto:tomasco...@gmail.com>) wrote:

> Raisin was the first proposed tool to build the API. We found it was
> Plack-only, and that it implemented an outdated version of
Swagger, which
> seemed a requirement for people proposing it.
>
> Mojolicious was found to be CGI-friendly, and also has a
Swagger2 plugin.
>
> I'm not saying those are blockers, but that was part of the
discussion.
>
Excellent thanks, that's the information I was after

Chris


--
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
<mailto: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/




--
---
Brendan A. Gallagher
ByWater Solutions
CEO

Support and Consulting for Open Source Software
Installation, Data Migration, Training, Customization, Hosting
and Complete Support Packages
Headquarters: Santa Barbara, CA - Office: Redding, CT
Phone # (888) 900-8944
http://bywatersolutions.com
i...@bywatersolutions.com <mailto:i...@bywatersolutions.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/

Re: [Koha-devel] Automatic renewal feature

[Eric Bégin]

Hi Holger,

This is a nice feature.

Instead of implementing this in the issuing rules, I think we could add 
an "Automatic renewal" checkbox on the checkout page and adding this 
value in the issues table.


The cronjob would look for those flags in order to automatically renew 
those loans if no there si no holds. A syspref could be use for your « 
Automatically renewal X days before due date ».


What do you think ?

Thanks for this RFC !

Eric Bégin
Solutions inLibro inc.

On 2014-01-17 05:44, Holger Meissner wrote:


Dear Koha developers,

I just created a RFC for a new "automatic renewal" feature in the Koha 
wiki and would greatly appreciate any feedback on it:


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

Especially let me know if you think that I should address bug 7413, 
before I start working on the new feature. I suppose, that would be 
the most reasonable approach?


Thank you!

Holger



___
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

[Eric Bégin]

I'm thinking about this type of addition for a long time so I'm all for it !

Couldn't we also use a WYSIWYG for editing notifications (when HTML is 
selected).


Cheers,

Eric Bégin
Solutions inLibro inc.

On 2014-01-17 06:14, Martin Renvoize wrote:
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 <mailto: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
<http://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
<mailto: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] Issue with boostrap translation in 3.14

[Eric Bégin]

Hi,

It seems that the script was not the problem.

We had a flaw in our work flow. We were not retrieving the new version 
of the .po file from the right location (that doesn't help) :)


I'm glad to see that it was not a major issue :)

Eric Bégin
Solutions inLibro inc.

On 2013-12-09 10:39, Philippe Blouin wrote:

(posted to both koha-translate and koha-devl)

Holà koha!

Anyone else has issue with boostrap translation in 3.14?  Seems a lot 
of strings are not picked up by "translate update" anymore, due to not 
being "obvious" to the tool anymore.


For example:
opac-tmpl/bootstrap/en/includes/masthead.inc : 131
 Search

If we put the string between   , then it's picked up and 
can be translated.
There are multiple cases like these.  Enough that we certainly don't 
want to hack all the files like this, if that can be avoided.


Anyone else has that issue?  We're translating to fr-CA, but I don't 
think the target language is related to the issue.


Suggestions are very welcomed (more so since we are on a tight schedule)

Best regards,
Philippe



--
Philippe Blouin,
Responsable du développement informatique

Tél.  : (888) 604-2627
philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.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/

[Koha-devel] RE : [Koha] Question of sax parser

[Eric Bégin]

Bonjour Sam,

You can simply move the following block at the end of your ParserDetails.ini 
file

[XML::LibXML::SAX]
http://xml.org/sax/features/namespaces = 1

Eric
www.inLibro.com

 Message d'origine 
De : Samuel Desseaux  
Date : 05/09/2013  5:00  (GMT-05:00) 
À : koha-devel@lists.koha-community.org,k...@lists.katipo.co.nz 
Objet : [Koha] Question of sax parser 
 
Hi,

During the install, when i run this command "./sax_parser_print.pl", 
i've  the following error

Koha wants something like:
 XML::LibXML::SAX::Parser=HASH(0x81fe220)
You have:
 XML::SAX::Expat=HASH(0x99127b0)
Looks bad, check INSTALL.* documentation.

I check my ParserDetails.ini and something miss (Sax Parser)

[XML::SAX::PurePerl]
http://xml.org/sax/features/namespaces = 1


[XML::LibXML::SAX]
http://xml.org/sax/features/namespaces = 1



[XML::SAX::Expat]
http://xml.org/sax/features/namespaces = 1
http://xml.org/sax/features/external-general-entities = 1
http://xml.org/sax/features/external-parameter-entities = 1

I think the following lines give the main reason but i don't know how to do



root@kohadev:/home/koha/kohaclone# cpan XML::LibXML::SAX::Parser
Going to read '/root/.cpan/Metadata'
   Database was generated on Thu, 05 Sep 2013 04:29:04 GMT
Running install for module 'XML::LibXML::SAX::Parser'
Running make for S/SH/SHLOMIF/XML-LibXML-2.0104.tar.gz
Checksum for 
/root/.cpan/sources/authors/id/S/SH/SHLOMIF/XML-LibXML-2.0104.tar.gz ok

   CPAN.pm: Going to build S/SH/SHLOMIF/XML-LibXML-2.0104.tar.gz

enable native perl UTF8
running xml2-config...didn't manage to get libxml2 config, guessing
options:
   LIBS='-L/usr/local/lib -L/usr/lib -lxml2 -lm'
   INC='-I/usr/local/include -I/usr/include'
If this is wrong, Re-run as:
   $ /usr/bin/perl Makefile.PL LIBS='-L/path/to/lib' 
INC='-I/path/to/include'

Checking for ability to link against xml2...no
Checking for ability to link against libxml2...libxml2, zlib, and/or the 
Math library (-lm) have not been found.
Try setting LIBS and INC values on the command line
Or get libxml2 from
   http://xmlsoft.org/
If you install via RPMs, make sure you also install the -devel
RPMs, as this is where the headers (.h files) are.

Also, you may try to run perl Makefile.PL with the DEBUG=1 parameter
to see the exact reason why the detection of libxml2 installation
failed or why Makefile.PL was not able to compile a test program.
No 'Makefile' created  SHLOMIF/XML-LibXML-2.0104.tar.gz
   /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
Running make test
   Make had some problems, won't test
Running make install
   Make had some problems, won't install
Could not read metadata file. Falling back to other methods to determine 
prerequisites

Thank you for your help

Best regards,

Samuel


___
Koha mailing list  http://koha-community.org
k...@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/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] RE : errors ldap

[Eric Bégin]

Bonjour Samuel,

It seems the category codes you are receiving from your LDAP server doesn't 
match your patrons' categories defined in Koha.

Double check also your date formats. You have some warning related to this too. 
I think they must be formatted as specified in you system preferences. 

Regards,

Eric Bégin

Tél  : 1-888-604-2627
Cell : 514-777-6572
inLibro | pour esprit libre | www.inLibro.com

 Message d'origine 
De : Samuel Desseaux  
Date : 19/08/2013  10:54  (GMT-05:00) 
À : k...@lists.katipo.co.nz,koha-devel@lists.koha-community.org 
Objet : [Koha-devel] errors ldap 
 
Hi,

Our koha is connected to our ldap now. During tests, we have some problems.
We have added 2 members the first time and it worked but we have this error

opac-user.pl: DBD::mysql::st execute failed: Cannot add or update a child row: 
a foreign key constraint fails (`bibecp`.`borrowers`, CONSTRAINT 
`borrowers_ibfk_1` FOREIGN KEY (`categorycode`) REFERENCES `categories` 
(`categorycode`)) at /home/koha/kohaclone/C4/Auth_with_ldap.pm line 296,  
line 581., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-main.pl?logout.x=1

Now, we can't add members any more

These are the logs

tail -f koha-opac-error_log
[Mon Aug 19 15:20:06 2013] [error] [client 138.195.48.28] File does not exist: 
/home/koha/kohaclone/koha-tmpl/images, referer: http://tst-koha.ecp.fr/
[Mon Aug 19 15:20:08 2013] [error] [client 138.195.48.28] client denied by 
server configuration: 
/home/koha/kohaclone/koha-tmpl/opac-tmpl/prog/fr-FR/includes/favicon.ico
[Mon Aug 19 15:20:10 2013] [error] [client 138.195.48.28] File does not exist: 
/home/koha/kohaclone/koha-tmpl/images, referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: Use of uninitialized value in string ne at 
/home/koha/kohaclone/C4/Auth.pm line 670,  line 581., referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at 
/home/koha/kohaclone/C4/Auth.pm line 780,  line 581., referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at 
/home/koha/kohaclone/C4/Auth.pm line 780,  line 581., referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: Illegal Date ' ' does not match 'metric' format: dd/mm/ 
at /home/koha/kohaclone/C4/SQLHelper.pm line 407., referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: Illegal Date ' ' does not match 'metric' format: dd/mm/ 
at /home/koha/kohaclone/C4/SQLHelper.pm line 407., referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: DBD::mysql::st execute failed: Column 'categorycode' cannot 
be null at /home/koha/kohaclone/C4/SQLHelper.pm line 184,  line 581., 
referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 15:20:22 2013] [error] [client 138.195.48.28] [Mon Aug 19 15:20:22 
2013] opac-user.pl: AddMember failed at 
/home/koha/kohaclone/C4/Auth_with_ldap.pm line 156., referer: 
http://tst-koha.ecp.fr/cgi-bin/koha/opac-user.pl
[Mon Aug 19 16:43:57 2013] [error] [client 138.195.30.33] client denied by 
server configuration: 
/home/koha/kohaclone/koha-tmpl/opac-tmpl/prog/fr-FR/includes/favicon.ico
[Mon Aug 19 16:43:57 2013] [error] [client 138.195.30.33] File does not exist: 
/home/koha/kohaclone/koha-tmpl/images, referer: http://tst-koha.ecp.fr/
[Mon Aug 19 16:43:58 2013] [error] [client 138.195.30.33] client denied by 
server configuration: 
/home/koha/kohaclone/koha-tmpl/opac-tmpl/prog/fr-FR/includes/favicon.ico
[Mon Aug 19 16:44:13 2013] [error] [client 138.195.30.33] [Mon Aug 19 16:44:13 
2013] opac-user.pl: Use of uninitialized value in string ne at 
/home/koha/kohaclone/C4/Auth.pm line 670,  line 581., referer: 
http://tst-koha.ecp.fr/
[Mon Aug 19 16:44:13 2013] [error] [client 138.195.30.33] [Mon Aug 19 16:44:13 
2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at 
/home/koha/kohaclone/C4/Auth.pm line 780,  line 581., referer: 
http://tst-koha.ecp.fr/
[Mon Aug 19 16:44:13 2013] [error] [client 138.195.30.33] [Mon Aug 19 16:44:13 
2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at 
/home/koha/kohaclone/C4/Auth.pm line 780,  line 581., referer: 
http://tst-koha.ecp.fr/
[Mon Aug 19 16:44:13 2013] [error] [client 138.195.30.33] [Mon Aug 19 16:44:13 
2013] opac-user.pl: DBD::mysql::st execu

[Koha-devel] Two Jobs available

[Eric Bégin]

Hello Koha !

A quick email to let your know that inLibro is currently looking to 
fulfill two great positions :


Lead programmer
Web developper

Selected candidates must speak french and are willing to move in 
beautiful Montreal.


More info is available on our website [in french] at 
http://www.inLibro.com/emplois.


Thank you for forwarding this email to your contacts/social networks. :)

Best regards,
--
Eric Bégin

Tél.  : (888) 604-2627
Cell. : (514) 777-6572
eric.be...@inlibro.com <mailto:ericbe...@inlibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.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] SQL reports [error]

[Eric Bégin]

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 = <>
AND DATE(dateaccessioned) BETWEEN <> 
AND <>;


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/

Re: [Koha-devel] Koha 3.8 release schedule & perltidy process

[Eric Bégin]

Hello all,

Have we considered using git's hooks for tidifying the code before 
checking it in, or even on the server, this would ensure that whoever 
does the checkin, it will be tidified.


Also, if we consider going with a global tidifying, a good timing could 
be when creating a new branch.


My 2 cents !

Eric Bégin
www.inLibro.com



On 2012-03-09 04:16, Marcel de Rooy wrote:


+1 for a gradual perl tidy too

Even then, still don't like the idea of blocking a patch for tabs and 
spaces ..



*Van:* koha-devel-boun...@lists.koha-community.org 
[koha-devel-boun...@lists.koha-community.org] namens Ian Walls 
[koha.sek...@gmail.com]

*Verzonden:* donderdag 8 maart 2012 20:21
*To:* Chris Cormack
*Cc:* Fischer, Katrin; koha-devel@lists.koha-community.org
*Onderwerp:* Re: [Koha-devel] Koha 3.8 release schedule & perltidy process

Chris,


Right, with the colossal commit option, one could have to

 1. Know the commit id of the change
 2. git blame something
 3. if that id comes up, then git checkout -b temporary
<>^
 4. git blame again

The more history we pile on top of that, the longer it'll take git to 
update the index, and then restore back to master when you're done.  
If you're tracing out lots of blames, then this can be a serious crimp 
in workflow.


-Ian

On Thu, Mar 8, 2012 at 13:50, Chris Cormack <mailto:chr...@catalyst.net.nz>> wrote:


* Ian Walls (koha.sek...@gmail.com <mailto:koha.sek...@gmail.com>)
wrote:
>Doing a large updating commit does not cost us any history.A
 It just
>counts as an "update" to the code, even though none of the
logic has
>changed.A A  This change would alter SLOC counts and such,
messing with
>our statistics, since we only want to measure intellectually
significant
>contributions (tidying someone else's work doesn't make it
yours).A  There
>is no way for Git to know if a change to a line of text is a
logical
>change or just a formatting change (aside from whitespace),
because Git
>doesn't understand Perl.A  There isn't too much we can do
about this.

It's not so much statistics I care about, although I do. But also that
it makes it hard to to do a git blame to find which commit actually
changed the line. Since now every line is changed by the same commit.

Chris
>
>So, best to keep cleaning up incrementally, I think.A  As we
move from C4
>to Koha, that'll be an opportunity to clean up all the modules
>
>-Ian
>
>2012/3/8 Jared Camins-Esakov mailto:jcam...@cpbibliography.com>>
>
>  +1 to a gradual perltidy
>
>  2012/3/8 Fischer, Katrin mailto:katrin.fisc...@bsz-bw.de>>
>
>I agree with Chris C. and Chris N. - I think what we
would win does
>not outweigh the loss of history.
>
>Katrin
>
>-UrsprA 1/4ngliche Nachricht-
>Von: koha-devel-boun...@lists.koha-community.org
<mailto:koha-devel-boun...@lists.koha-community.org> im Auftrag
von Chris
>Nighswonger
>Gesendet: Do 08.03.2012 19:26
>An: Chris Cormack
>Cc: koha-devel@lists.koha-community.org
<mailto:koha-devel@lists.koha-community.org>
>Betreff: Re: [Koha-devel] Koha 3.8 release schedule &
perltidy process
>
>2012/3/8 Chris Cormack mailto:ch...@bigballofwax.co.nz>>
>
> > My counter proposal is tidy as you go. Fix code as you touch it.
> >
> > With vim (and other editors) you can easily tidy a block,
doing that
>as
> > code is changed would be my preference.
> >
>
>I'd prefer a "pay-as-you-go" approach as well. We could
simply require
>all
>work to be tidied before submitting.
>
>Slow? Yes, but not nearly as messy and preserves the history.
>
>Kind Regards,
>Chris
>
>___
>Koha-devel mailing list
> Koha-devel@lists.koha-community.org
<mailto: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/
>
>  --
>  Jared Camins-Esakov
>  Bibliographer, C & P Bibliography Services, LLC
>  (pho

Re: [Koha-devel] Perl - Files missed on config

[Eric Bégin]

Tom,

What type of modifications do you have to do in those files when you are 
updating your version?


Eric

On 2012-01-12 12:39, Tom Hanstra wrote:

Koha Developers,

I'm a bit of a lurker on the list and don't do much in the line of 
development.  So, I'm not sure how best to officially get some fixes 
requested.


But each time I install or upgrade a new version of Koha, I 
consistently have to edit a number of files in the koha software 
because I run a different version of perl than the default 
/usr/bin/perl.  I just upgraded one of my instances to 3.6.2 and ran 
into this again with this set of files, which I then have to manually 
edit:


1029$ find . -type f -exec grep "/usr/bin/perl" {} \; -ls
#!/usr/bin/perl
289557514 -rwxr-xr-x   1 root root 3313 Dec 22 17:55 
./misc/translator/translate

#!/usr/bin/perl
28340370   16 -rw-r--r--   1 root root 8457 Dec 22 17:55 
./lib/C4/ShelfBrowser.pm

#!/usr/bin/perl
283411224 -rwxr-xr-x   1 root root 3153 Dec 22 17:55 
./bin/maintenance/borrowers-force-messaging-defaults

#!/usr/bin/perl
28341185   16 -rwxr-xr-x   1 root root 8703 Dec 22 17:55 
./bin/admin/koha-preferences

#!/usr/bin/perl
28337824   12 -rwxr-xr-x   1 root root 7848 Dec 22 17:55 
./opac/cgi-bin/opac/unapi

#!/usr/bin/perl
59236794 -rwxr-xr-x   1 root root 2775 Dec 22 17:55 
./intranet/cgi-bin/svc/new_bib

#!/usr/bin/perl
59236804 -rwxr-xr-x   1 root root 3255 Dec 22 17:55 
./intranet/cgi-bin/svc/bib

#!/usr/bin/perl
5923681   12 -rwxr-xr-x   1 root root 4659 Dec 22 17:55 
./intranet/cgi-bin/svc/bib_profile

#!/usr/bin/perl
59236854 -rwxr-xr-x   1 root root 2709 Dec 22 17:55 
./intranet/cgi-bin/svc/config/systempreferences

#!/usr/bin/perl
59236844 -rwxr-xr-x   1 root root 1948 Dec 22 17:55 
./intranet/cgi-bin/svc/authentication

#!/usr/bin/perl
5923910   16 -rwxr-xr-x   1 root root 9502 Dec 22 17:55 
./intranet/cgi-bin/acqui/pdfformat/layout2pages.pm

#!/usr/bin/perl
5923914   24 -rwxr-xr-x   1 root root16999 Dec 22 17:55 
./intranet/cgi-bin/acqui/pdfformat/layout3pages.pm

#!/usr/bin/perl
289483504 -rwxr-xr-x   1 root root 3407 Dec 22 17:55 
./intranet/cgi-bin/reports/itemtypes.plugin

#!/usr/bin/perl
28948413   12 -rwxr-xr-x   1 root root 7939 Dec 22 17:55 
./intranet/cgi-bin/reports/issues_by_borrower_category.plugin


Is there a (preferably low overhead) way to report these other than 
the way I'm doing by hitting the list?


Thanks,
Tom

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] RFC : Local cover images

[Eric Bégin]

 Hi Koustabha,

If we are going to keep information in a MARC field, why not put the 
file name directly.  That way, it doesn't have to be only a number, I 
could have HarryPotter_V1.jpg or even a remote path.


I looked up the MARC standard and it would make sense to store the path 
to the file in the 856$u field, specifying Image (or Cover) in the $3 
field.  There is such an example in

http://www.loc.gov/marc/authority/ad856.html.

*856* 
*4#**$3*image*$u*http://www.ibiblio.org/wm/paint/auth/vinci/joconde/joconde.jpg


A syspref could also be added for a base directory in which are located 
the files.


My 2 cents,

Eric

On 2010-12-11 07:14, Koustubha Kale wrote:

Hi Ian,

On Sat, Dec 11, 2010 at 5:03 PM, Ian Bays  wrote:

Hi Koustubha
That's a great feature to add to Koha.  Congratulations on this.
The only part that I worry about is using the bibliomumber for access: If
you were to ever re-install and wanted to export the bib data and re-import
then you would be likely to get different biblionumbers for records, so you
would lose the link to the images.
I would have thought that there should be some unique number or code for
each title which you might put into a tag such as the 024 MARC21 tag (Other
Standard Identifier):
http://www.loc.gov/marc/bibliographic/bd024.html
Maybe have the tag and subfield as a system pref?

Valid point about the export and re-import and a good idea of linking
with a marc tag. Thank you.

Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address  : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
Naka, Thane (w),
 Maharashtra, India, Pin : 400601.
TeleFax  : +91-22-21720108, +91-22-21720109
Mobile : +919820715876
Website  :http://www.anantcorp.com
Blog :http://www.anantcorp.com/blog/?author=2
___
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/