Re: [Koha-devel] [Koha] Call for news - Newsletter September 2021

[jesse...@edgetech.com.my]

Dear Victor, Kindly guide us the way to one shot upload, in order to easy and save the time. Thanks! Regards, JesseLemonjar Software Media Sdn BhdSent from my Huawei phone Original message From: Victor Grousset/tuxayo Date: Sun, 26 Sep 2021, 6:38 amTo: JESSE KAH , koha-devel Cc: Hean Yoon Chong Subject: Re: [Koha-devel] [Koha] Call for news - Newsletter September 2021On 21-09-25 08:49, JESSE KAH wrote:> Good suggestion though.> The Chinese translation is desperately required by one of our client that time, so we translate in our way for faster result. (*^__^*)> We will get our people to go one-by-one to upload there then.Great! :DBut fear not, you shouldn't need to do it one-by-one, it's possible to upload all the translations to replace the existing ones.Cheers,-- Victor Grousset/tuxayo___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] [Koha] Call for news - Newsletter September 2021

[JESSE KAH]

Dear Victor,

Good suggestion though.
The Chinese translation is desperately required by one of our client that time, 
so we translate in our way for faster result. (*^__^*)
We will get our people to go one-by-one to upload there then.
Do give us more time on that.
Meanwhile, the community may put it at any wiki page that enable user to 
download the simplified Chinese translation from our drive then. 

Thanks.


Regards,
Jesse Kah 
Lemonjar Software Media Sdn. Bhd. (Malaysia) 

On 25/09/2021, 6:45 AM, "Victor Grousset/tuxayo"  wrote:

Hi :)

On 21-09-21 10:08, JESSE KAH wrote:
> Update from my previous email for *Chinese Translation*:
> 
> Development on*Full Chinese Simplified Translation*on Koha version 20.11 
> accomplished.
> 
> Users may download via 
> 
https://drive.google.com/drive/folders/13HPm3xXHEPPZa9YCu65CTAfwUoWnVQ5x?usp=sharing
 
> 
<https://drive.google.com/drive/folders/13HPm3xXHEPPZa9YCu65CTAfwUoWnVQ5x?usp=sharing>
 
> for the full Chinese features of it.

Congratulations on having the translation complete! It was only around 
half complete before.
Do you have plans to integrate it directly into Koha via the translation 
platform?
https://translate.koha-community.org/zh_CN/20.05/
So it will be available without any action to all zh_CN Koha 
installations. It's also the first step to enable the translation to be 
kept version to version which will also benefit your and your customers 
in the future upgrades.

I can guide you or one of your colleagues for the procedure.
It should be something like this
- you create an account on the translation platform
- I'll make a request so your account get the direct translation rights 
for zh_CN
- you upload your files in the platform

Cheers,

-- 
Victor Grousset/tuxayo


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

Re: [Koha-devel] [Koha] Call for news - Newsletter September 2021

[JESSE KAH]

Dear Michael,

 

Update from my previous email for Chinese Translation:

 

Development on Full Chinese Simplified Translation on Koha version 20.11 
accomplished.

Users may download via 
https://drive.google.com/drive/folders/13HPm3xXHEPPZa9YCu65CTAfwUoWnVQ5x?usp=sharing
 for the full Chinese features of it.

 

Thanks & have a nice day!

 

 

Regards,

Jesse

Lemonjar Software Media Sdn. Bhd.

 

From: JESSE KAH 
Date: Tuesday, 21 September 2021 at 11:56 AM
To: Koha Newsletter , koha , 
koha-devel 
Cc: Michael Kuhn 
Subject: Re: [Koha] Call for news - Newsletter September 2021

 

Dear Michael,

 

This is Jesse from Lemonjar Software Media Sdn. Bhd.

We have new library implemented Koha and would like to share to the community.

 

Malaysia Baptist Theological Seminary - 马来西亚浸信会神学院 (MBTS)

News is published at Lemonjar website and can be access via: 
https://www.lemonjar.com.my/index.php/2021/09/21/koha-to-mbts/ 

MBTS OPAC can be access via - https://library.mbts.org.my/ 

Koha version 20.11

System goes live on 1st September 2021.

 

Development on Full Chinese Translation on version 20.11 is on the way.

Once completed, we shall contribute to the community as well.

 

Thanks!

 

 

 

Stay safe and alert to fight against Covid-19

 

 

Best Regards,

(Mdm.) Jesse Kah

Lemonjar Software Media Sdn. Bhd.

-- Managing Director --

Mobile: +6 (016) 8606 826

Tel: +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)

Fax: +6 (088) 713226

Website:  https://www.lemonjar.com.my  

  https://www.edgetech.com.my 

https://www.czur.my 

Other Email: lemonja...@gmail.com / lemonjar.sa...@gmail.com 

 

 

Lemonjar Facebook page: https://www.facebook.com/lemonjarsoftmed/

Czur Facebook page: https://www.facebook.com/CZURMalaysia   

Edgetech Facebook page: https://www.facebook.com/edgetechengineering/ 

YouTube page: https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured 

 

 

Disclamer: Any reproduction, dissemination, copying, disclosure, modification, 
distribution and keeping of this message, without prior written consent of the 
sender are strictly prohibited.

 

Lemonjar Software Media Sdn. Bhd. and Edge Tech Engineering Is specialising in 
manufacturing comprehensive solution in Library Automation Equipment Products – 
EM, RFID (HF/ UHF) and Hybrid solution; As well as having 12-years experiences 
in Open Source KOHA ILS System including customization and software 
development; as well as other Open Source system solutions specifically for 
Library.

 

Edge Tech Engineering also specializes in the reselling, marketing and 
distribution of many prestigious and leading brands of ICT products, namely, 
HP, Acer, Dell, Asus, APC, Autodesk, Epson, Supermicro, Intel, Lenovo, 
Microsoft, Huawei, Symantec, Yes, Aruba, Cisco, Fujitsu, IBM, Intermec, 
Juniper, Oracle, Trend Micro, BitDefender, VMWare, Brother, Canon, Zebra 
Motorola and others.

 

Czur Malaysia is Smart Scanner solutions range from Shine Series, Aurora 
Series, ET Series and M Series all come with auto OCR processing features.

 

 

 

 

On 19/09/2021, 3:13 PM, "JESSE KAH"  wrote:

 

 

 

On 13/09/2021, 7:44 PM, "Koha on behalf of Koha Newsletter" 
 wrote:

 

Hi

 

I'm collecting news for the September 2021 Koha Community Newsletter.

Please send anything noteworthy to:

 

kohanews (at) gmail (dot) com

 

News criteria:

* News items can be of any length.

* Images are fine.

* Anything and everything Koha.

* Submit by the 26th of the month.

 

Text format criteria:

* Just structured plain text, or

* HTML text to include tables or similar

 

For events:

* Consider adding your event to the Koha Community calendar at

https://koha-community.org/calendar/

 

Thank you!

 

Michael Kuhn

Editor, Koha Community Newsletter

___

 

Koha mailing list  http://koha-community.org

k...@lists.katipo.co.nz

Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

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

Re: [Koha-devel] [Koha] Call for news - Newsletter September 2021

[JESSE KAH]

Dear Michael,

 

This is Jesse from Lemonjar Software Media Sdn. Bhd.

We have new library implemented Koha and would like to share to the community.

 

Malaysia Baptist Theological Seminary - 马来西亚浸信会神学院 (MBTS)

News is published at Lemonjar website and can be access via: 
https://www.lemonjar.com.my/index.php/2021/09/21/koha-to-mbts/ 

MBTS OPAC can be access via - https://library.mbts.org.my/ 

Koha version 20.11

System goes live on 1st September 2021.

 

Development on Full Chinese Translation on version 20.11 is on the way.

Once completed, we shall contribute to the community as well.

 

Thanks!

 

 

 

Stay safe and alert to fight against Covid-19

 

 

Best Regards,

(Mdm.) Jesse Kah

Lemonjar Software Media Sdn. Bhd.

-- Managing Director --

Mobile: +6 (016) 8606 826

Tel: +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)

Fax: +6 (088) 713226

Website:  https://www.lemonjar.com.my  

  https://www.edgetech.com.my 

https://www.czur.my 

Other Email: lemonja...@gmail.com / lemonjar.sa...@gmail.com 

 

 

Lemonjar Facebook page: https://www.facebook.com/lemonjarsoftmed/

Czur Facebook page: https://www.facebook.com/CZURMalaysia   

Edgetech Facebook page: https://www.facebook.com/edgetechengineering/ 

YouTube page: https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured 

 

 

Disclamer: Any reproduction, dissemination, copying, disclosure, modification, 
distribution and keeping of this message, without prior written consent of the 
sender are strictly prohibited.

 

Lemonjar Software Media Sdn. Bhd. and Edge Tech Engineering Is specialising in 
manufacturing comprehensive solution in Library Automation Equipment Products – 
EM, RFID (HF/ UHF) and Hybrid solution; As well as having 12-years experiences 
in Open Source KOHA ILS System including customization and software 
development; as well as other Open Source system solutions specifically for 
Library.

 

Edge Tech Engineering also specializes in the reselling, marketing and 
distribution of many prestigious and leading brands of ICT products, namely, 
HP, Acer, Dell, Asus, APC, Autodesk, Epson, Supermicro, Intel, Lenovo, 
Microsoft, Huawei, Symantec, Yes, Aruba, Cisco, Fujitsu, IBM, Intermec, 
Juniper, Oracle, Trend Micro, BitDefender, VMWare, Brother, Canon, Zebra 
Motorola and others.

 

Czur Malaysia is Smart Scanner solutions range from Shine Series, Aurora 
Series, ET Series and M Series all come with auto OCR processing features.

 

 

 

 

On 19/09/2021, 3:13 PM, "JESSE KAH"  wrote:

 

 

 

    On 13/09/2021, 7:44 PM, "Koha on behalf of Koha Newsletter" 
 wrote:

 

    Hi

 

    I'm collecting news for the September 2021 Koha Community Newsletter.

    Please send anything noteworthy to:

 

    kohanews (at) gmail (dot) com

 

    News criteria:

    * News items can be of any length.

    * Images are fine.

    * Anything and everything Koha.

    * Submit by the 26th of the month.

 

    Text format criteria:

    * Just structured plain text, or

    * HTML text to include tables or similar

 

    For events:

    * Consider adding your event to the Koha Community calendar at

    https://koha-community.org/calendar/

 

    Thank you!

 

    Michael Kuhn

    Editor, Koha Community Newsletter

    ___

 

    Koha mailing list  http://koha-community.org

    k...@lists.katipo.co.nz

    Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

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

Re: [Koha-devel] [Koha] Call for news - Newsletter August 2021

[JESSE KAH]

Dear Michael,

 

Yes. The four libraries did goes live in the last 3-months.

I’ve update below in italic, with additional info on their architecture setup 
environment.

At the same time, I’ve also requested for login for the the update in 
https://wiki.koha-community.org/wiki/KohaUsers/SoutheastAsia.

 

Thanks for your check-up too. =)

 

1. The Federal Court of Malaysia

 Koha version 19.11 (bi-language: English and Bahasa Malaysia)

 Their OPAC is open for public to do searching via - 
https://libkoha.kehakiman.gov.my/ 

 However, login is only available for the staff of Federal Court of 
Malaysia via Active Directory login.

 Architecture setup in 3-tier environment.

 System goes live: mid-July 2021

 

2. The Attorney General of the state of Sabah, Malaysia

 Koha version 20.05

 Implemented version 16 during year 2018 and recently upgraded to version 
20.05.

 Their searching in OPAC is ready only for internal Attorney General's 
access after login - https://sagclibrary.sabah.gov.my/ 

 Architecture setup in 2-tier environment.

 System goes live: mid-July 2021

 

3. Library of the Ministry of National Unity

Koha version 20.05 (bi-language: English and Bahasa Malaysia)

Their OPAC is open for public to do searching via - 
http://pusatsumber.perpaduan.gov.my/.

Architecture setup in single-tier environment.

System goes live: early Aug 2021

 

4. Malaysia Institute of Architects (PAM)

Koha version 18.11

Implementation of Koha is done some times ago, however their OPAC is 
recently open for public access with re-designed new look.

The searching in OPAC is closed and only available for registered 
architects to their organization, and self-registration is available via OPAC.

PAM OPAC can be access via: http://library.pam.org.my:8000/ 

Architecture setup in single-tier environment.

System goes live: early July 2021

 

 

 

Regards,

Jesse

Lemonjar Software Media Sdn. Bhd. (Malaysia)

 

 

From: Koha Newsletter 
Date: Wednesday, 18 August 2021 at 5:53 AM
To: JESSE KAH 
Cc: oha , koha-devel 

Subject: Re: [Koha] Call for news - Newsletter August 2021

 

Hi Jesse

 

Thanks for your e-mail!

 

Did any of the mentioned four libraries go live in the last 1-3 months? If not 
then they do not qualify for the newsletter (which should contain news, of 
course). However, you could always add your implementations of Koha at 
https://wiki.koha-community.org/wiki/KohaUsers/SoutheastAsia

 

Best wishes: MIchael

 

On Mon, Aug 16, 2021 at 10:13 AM JESSE KAH  wrote:

Dear Michael,

 

Good day!

This is Jesse from Lemonjar Software Media Sdn. Bhd., Malaysia.

We have few implementation of Koha site in Malaysia and would like to share 
with the community as follow:

 

1. The Federal Court of Malaysia

 Koha version 19.11 (bi-language: English and Bahasa Malaysia)

 Their OPAC is open for public to do searching via - 
https://libkoha.kehakiman.gov.my/ 

 However, login is only available for the staff of Federal Court of 
Malaysia via Active Directory login.

 

2. The Attorney General of the state of Sabah, Malaysia

 Koha version 20.05 

 Their searching in OPAC is ready only for internal Attorney General's 
access after login - https://sagclibrary.sabah.gov.my/ 

 

3. Library of the Ministry of National Unity

Koha version 20.05 (bi-language: English and Bahasa Malaysia)

Their OPAC is open for public to do searching via - 
http://pusatsumber.perpaduan.gov.my/.

 

4. Malaysia Institute of Architects (PAM)

Koha version 18.11

Implementation of Koha is done some times ago, however their OPAC is 
recently open for public access with re-designed new look.

The searching in OPAC is closed and only available for registered 
architects to their organization, and self-registration is available via OPAC.

PAM OPAC can be access via: http://library.pam.org.my:8000/ 

 

 

Thanks & have a blessing day!

 

 

Stay safe and alert to fight against Covid-19

 

 

Best Regards,

(Mdm.) Jesse Kah

Lemonjar Software Media Sdn. Bhd.

-- Managing Director --

Mobile: +6 (016) 8606 826

Tel: +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)

Fax: +6 (088) 713226

Website:  https://www.lemonjar.com.my  

  https://www.edgetech.com.my 

https://www.czur.my 

Other Email: lemonja...@gmail.com / lemonjar.sa...@gmail.com 

 

 

Lemonjar Facebook page: https://www.facebook.com/lemonjarsoftmed/

Czur Facebook page: https://www.facebook.com/CZURMalaysia   

Edgetech Facebook page: https://www.facebook.com/edgetechengineering/ 

YouTube page: https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured 

 

 

Disclamer: Any reproduction, dissemination, copying, disclosure, modification, 
distribution and keeping of this message, without prior written consent of the 
sender are strictly prohibited.

 

Lemonjar Software Media Sdn. Bhd. and Edge Tech Enginee

Re: [Koha-devel] [Koha] Call for news - Newsletter August 2021

[JESSE KAH]

Dear Michael,

 

Good day!

This is Jesse from Lemonjar Software Media Sdn. Bhd., Malaysia.

We have few implementation of Koha site in Malaysia and would like to share 
with the community as follow:

 

1. The Federal Court of Malaysia

 Koha version 19.11 (bi-language: English and Bahasa Malaysia)

 Their OPAC is open for public to do searching via - 
https://libkoha.kehakiman.gov.my/ 

 However, login is only available for the staff of Federal Court of 
Malaysia via Active Directory login.

 

2. The Attorney General of the state of Sabah, Malaysia

 Koha version 20.05 

 Their searching in OPAC is ready only for internal Attorney General's 
access after login - https://sagclibrary.sabah.gov.my/ 

 

3. Library of the Ministry of National Unity

    Koha version 20.05 (bi-language: English and Bahasa Malaysia)

    Their OPAC is open for public to do searching via - 
http://pusatsumber.perpaduan.gov.my/.

 

4. Malaysia Institute of Architects (PAM)

    Koha version 18.11

    Implementation of Koha is done some times ago, however their OPAC is 
recently open for public access with re-designed new look.

    The searching in OPAC is closed and only available for registered 
architects to their organization, and self-registration is available via OPAC.

    PAM OPAC can be access via: http://library.pam.org.my:8000/ 

 

 

Thanks & have a blessing day!

 

 

Stay safe and alert to fight against Covid-19

 

 

Best Regards,

(Mdm.) Jesse Kah

Lemonjar Software Media Sdn. Bhd.

-- Managing Director --

Mobile: +6 (016) 8606 826

Tel: +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)

Fax: +6 (088) 713226

Website:  https://www.lemonjar.com.my  

  https://www.edgetech.com.my 

https://www.czur.my 

Other Email: lemonja...@gmail.com / lemonjar.sa...@gmail.com 

 

 

Lemonjar Facebook page: https://www.facebook.com/lemonjarsoftmed/

Czur Facebook page: https://www.facebook.com/CZURMalaysia   

Edgetech Facebook page: https://www.facebook.com/edgetechengineering/ 

YouTube page: https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured 

 

 

Disclamer: Any reproduction, dissemination, copying, disclosure, modification, 
distribution and keeping of this message, without prior written consent of the 
sender are strictly prohibited.

 

Lemonjar Software Media Sdn. Bhd. and Edge Tech Engineering Is specialising in 
manufacturing comprehensive solution in Library Automation Equipment Products – 
EM, RFID (HF/ UHF) and Hybrid solution; As well as having 12-years experiences 
in Open Source KOHA ILS System including customization and software 
development; as well as other Open Source system solutions specifically for 
Library.

 

Edge Tech Engineering also specializes in the reselling, marketing and 
distribution of many prestigious and leading brands of ICT products, namely, 
HP, Acer, Dell, Asus, APC, Autodesk, Epson, Supermicro, Intel, Lenovo, 
Microsoft, Huawei, Symantec, Yes, Aruba, Cisco, Fujitsu, IBM, Intermec, 
Juniper, Oracle, Trend Micro, BitDefender, VMWare, Brother, Canon, Zebra 
Motorola and others.

 

Czur Malaysia is Smart Scanner solutions range from Shine Series, Aurora 
Series, ET Series and M Series all come with auto OCR processing features.

 

 

 

On 13/08/2021, 3:47 PM, "Koha on behalf of Koha Newsletter" 
 wrote:

 

    Hi

 

    I'm collecting news for the August 2021 Koha Community Newsletter.

    Please send anything noteworthy to:

 

    kohanews (at) gmail (dot) com

 

    News criteria:

    * News items can be of any length.

    * Images are fine.

    * Anything and everything Koha.

    * Submit by the 26th of the month.

 

    Text format criteria:

    * Just structured plain text, or

    * HTML text to include tables or similar

 

    For events:

    * Consider adding your event to the Koha Community calendar at

    https://koha-community.org/calendar/

 

    Thank you!

 

    Michael Kuhn

    Editor, Koha Community Newsletter

    ___

 

    Koha mailing list  http://koha-community.org

    k...@lists.katipo.co.nz

    Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

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

Re: [Koha-devel] SIG DIE in returns.pl

[Jesse]

Just to confirm, that was added as a debugging aid and I forgot to take it
out when I was done. Thanks for catching it!

2017-12-11 1:31 GMT-07:00 Fridolin SOMERS <fridolin.som...@biblibre.com>:

> Cool, thanks for creating the post on bugzilla.
> I see it is Passed QA
>
>
> Le 04/12/2017 à 20:09, Jonathan Druart a écrit :
>
>> See bug 19746, please SO+QA
>>
>> On Thu, 30 Nov 2017 at 05:57 Fridolin SOMERS <
>> fridolin.som...@biblibre.com>
>> wrote:
>>
>> Hie,
>>>
>>> With plack when some code fails, there is always in log a reference to
>>> circ/returns.pl o_O at start of stack trace.
>>>
>>> I found that there is in this page :
>>>
>>> use Carp 'verbose';
>>> $SIG{ __DIE__ } = sub { Carp::confess( @_ ) };
>>>
>>> Added by commit bb6277ffcc593685554112d770ac273c9efeda33
>>> Bug 14464: Add ability to cancel waiting holds from checkin screen
>>>
>>> Is this for debug purpopse only ?
>>> Why only this page ?
>>> Should it be moved to plack.psgi ?
>>>
>>> Regards,
>>>
>>> --
>>> Fridolin SOMERS <fridolin.som...@biblibre.com>
>>> BibLibre - software and system maintainer
>>> ___
>>> Koha-devel mailing list
>>> Koha-devel@lists.koha-community.org
>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org/
>>> git : http://git.koha-community.org/
>>> bugs : http://bugs.koha-community.org/
>>>
>>>
>>
> --
> Fridolin SOMERS <fridolin.som...@biblibre.com>
> BibLibre - software and system maintainer
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Write good bug report titles and commit messages

[Jesse]

Strong +1.

2017-08-31 8:10 GMT-06:00 Jonathan Druart <
jonathan.dru...@bugs.koha-community.org>:

> Hi devs,
>
> I would like to do a little reminder about the bug report titles and
> commit messages.
>
> For bugs:
> The bug report title must shortly tell what the *bug* is, whereas the
> commit messages must tell what the *fix* does. Sometimes they are not
> related at all.
> For instance:
> - bug report titles: "Feature X is not working correctly when Y is
> enabled", "Click on button 'Save' does not save the record", "Saving stuff
> on screen X does not work", "This script generates error logs", "Mystake is
> misspelled in this script", "Behaviour X no longer work as expected" etc.
> - commit messages: "Fix Feature X when Y is enabled", "Make sure behaviour
> is correct when button is clicked", "Remove warnings from this script",
> "Correct spelling of mistake in this script", "Fix regression on behaviour
> X" etc.
>
> For enhancements / new feature:
> We could have the same title and commit messages in some cases.
> - bug report titles: "Add new awesome feature", "Add the ability to do
> that", "Code is duplicated in method Koha::Stuff->method"
> - commit messages: "Add new awesome feature", "Add the ability to do
> that", "Remove code duplication in method Koha::Stuff->method"
>
> Note that "Address comment #42" is a terrible commit message.
>
> Then, I would like to standardize the commit messages a bit.
> We have "Bug 12345 - ", "Bug 12345: ", "Bug 12345"
> and "[follow-up]", "(follow-up)", "[QA Followup]", etc.
>
> I would suggest:
>   "Bug 12345: you commit message"
> And reject any commit messages with only "follow-up" (or whatever how it
> is written), but accept
>   "Bug 12345: (follow-up) same commit message as before"
> If you forgot something, even if
>   "Bug 12345: (follow-up) This was missing"
>
> And QA follow-ups (added by QA team member):
>   "Bug 12345: "(QA follow-up) Add/remove this stuff"
>
> I am going to suggest these change during the next dev meetings.
> If accepted I will change the bug report titles and commit messages before
> the push during few weeks, then ask authors to do it themselves (patches
> from new contributors will not be rejected for that reason).
>
> You should also read or re-read:
> https://wiki.koha-community.org/wiki/Bug_Reporting_Guidelines
> https://wiki.koha-community.org/wiki/Commit_messages
>
> Cheers,
> Jonathan
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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 for ES6 development on the staff client

[Jesse]

2017-08-29 17:33 GMT-06:00 David Cook <dc...@prosentient.com.au>:

> Thanks for the info, Jesse. I haven’t reviewed Bugzilla or Github, but I
> just have a couple of questions.
>
>
>
> If I understand correctly, we’ll be bundling the Javascript packages in
> with Koha for deployment, is that right?
>

Correct. After being built, all of the necessary JS (our own transpiled
code and its dependencies) will be bundled together.


>
>
> If that’s the case, will only the build machine will need Nodejs, npm,
> yarn, Gulp, Browserify, Babel, etc? If so, then the onus of these
> additional dependencies is really just for developers or people installing
> from source? The Debian packages would just the transpiled versions of the
> Javascript? I imagine that would satisfy the community’s desire to just use
> upstream packages from Debian?
>

Correct.


>
>
> For those of us who do install from source, would this transpiling process
> be automated via the Makefile?
>

It easily could be. In my original email, the global install (sudo npm
install -g) of yarn was purely for convenience. The entire process could
become:

$ sudo apt install nodejs npm # or koha-builddeps or koha-jsdeps (or
koha-perldeps if we feel like being lazy)
$ make build-js

Where the Makefile took care of downloading yarn, installing all the JS
dependencies, and building the files.


>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>
>
> *From:* koha-devel-boun...@lists.koha-community.org [mailto:
> koha-devel-boun...@lists.koha-community.org] *On Behalf Of *Jesse
> *Sent:* Wednesday, 30 August 2017 7:27 AM
> *To:* koha-devel@lists.koha-community.org
> *Subject:* [Koha-devel] Proposal for ES6 development on the staff client
>
>
>
>
>
> As part of my work on bug 15522 <https://bugs.koha-community.
> org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a
> React clone with a friendlier license). We've established that this needs
> ES6[1] in previous discussions on the mailing list and in IRC. From there,
> we found IE's many limitations meant we needed a transpiler[2] to to make
> use of these features.
>
> Owen and I have been thinking about the easiest way to do this, and this
> is the lowest-friction process we've come up with to transpile ES6:
>
> $ sudo apt-get install nodejs npm
>
> $ sudo npm install -g yarn
>
> $ yarn install
>
> $ yarn build
>
> Yarn is a somewhat faster version of npm, the de-facto JavaScript package
> manager. Normally, this would be a pointless addition, but the npm in the
> Debian repositories is 3 major versions out of date, and therefore not a
> great option. Many npm packages simply fail to install.
>
> This is a constant problem with the JS packages in the Debian repos; most
> if not all of the tools that one might want either are completely
> unpackaged or woefully out of date. Packaging them ourselves means working
> our way through a number of dependencies (see [3] for an example). Any
> frontend build process worth our time cannot solely use packages from the
> upstream repos.
>
> That aside, this build process will use Gulp, Browserify and Babel to take
> any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a
> matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that
> any new files will not have to be manually whitelisted.
>
> You can see a working example at https://github.com/pianohacker/koha,
> branch bz15522. I'm currently committing the built versions of the files,
> but this is purely for convenience of prototyping. The page in question is
> admin/policy.pl, and the relevant code is at .../prog/js/src/admin/policy.js
> .
>
>
>
> [1] ECMAScript 6, a semi-recent version of JavaScript with a large number
> of new features, including a nice class syntax, arrow functions, and
> destructuring assignment.
>
> [2] A tool that transforms ES6 syntax (and the JSX syntax extension used
> by (P)react) into something that can be run by older browsers, including IE.
> [3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp
>
>
>
> --
>
> Jesse Weaver
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Proposal for ES6 development on the staff client

[Jesse]

As part of my work on bug 15522 <https://bugs.koha-community.
org/bugzilla3/show_bug.cgi?id=15522>, I've been working with Preact (a
React clone with a friendlier license). We've established that this needs
ES6[1] in previous discussions on the mailing list and in IRC. From there,
we found IE's many limitations meant we needed a transpiler[2] to to make
use of these features.

Owen and I have been thinking about the easiest way to do this, and this is
the lowest-friction process we've come up with to transpile ES6:

$ sudo apt-get install nodejs npm
$ sudo npm install -g yarn
$ yarn install
$ yarn build

Yarn is a somewhat faster version of npm, the de-facto JavaScript package
manager. Normally, this would be a pointless addition, but the npm in the
Debian repositories is 3 major versions out of date, and therefore not a
great option. Many npm packages simply fail to install.

This is a constant problem with the JS packages in the Debian repos; most
if not all of the tools that one might want either are completely
unpackaged or woefully out of date. Packaging them ourselves means working
our way through a number of dependencies (see [3] for an example). Any
frontend build process worth our time cannot solely use packages from the
upstream repos.

That aside, this build process will use Gulp, Browserify and Babel to take
any files in koha-tmpl/intranet-tmpl/prog/js/src, and compile them into a
matching file in koha-tmpl/intranet-tmpl/prog/js/built . This means that
any new files will not have to be manually whitelisted.

You can see a working example at https://github.com/pianohacker/koha,
branch bz15522. I'm currently committing the built versions of the files,
but this is purely for convenience of prototyping. The page in question is
admin/policy.pl, and the relevant code is at
.../prog/js/src/admin/policy.js .

[1] ECMAScript 6, a semi-recent version of JavaScript with a large number
of new features, including a nice class syntax, arrow functions, and
destructuring assignment.
[2] A tool that transforms ES6 syntax (and the JSX syntax extension used by
(P)react) into something that can be run by older browsers, including IE.
[3] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp


-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Circulation Rules RFC - new proposed frontend

[Jesse]

I've updated the proposed UI at
https://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC#Frontend
.

Please see the notes below the screenshots, but the essential idea is a
hybrid of the old and (formerly proposed) new UIs, with a table that grows
as needed. Comments appreciated.

If you wish to try out this very early prototype, please see
https://github.com/pianohacker/koha, branch bz15522 (or visit
https://github.com/pianohacker/koha/tree/bz15522). The page in question is
admin/policy.pl, and the relevant code is at
.../prog/js/src/admin/policy.js .

Background: the core idea of this new circulation rules project is to allow
librarians to specify only those rules that they need to be different, and
let the rest inherit from more general settings. This should result in a
more pleasant workflow, especially for large libraries, and a UI that no
longer scrolls off the side of your monitor.

-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] MARC frameworks in Koha

[Jesse]

I can't respond to the librarian part of this, but I strongly agree as a
developer. To make things worse, I believe there are _tiny parts_ of Koha
that respect the per-framework mappings, leading a librarian into a false
sense of hope.

+1 to removing per-framework mappings in the UI and code.

2017-08-07 7:12 GMT-06:00 Marcel de Rooy <m.de.r...@rijksmuseum.nl>:

> Hi developers or librarians,
>
>
>
> If you are interested in say sorting search results or lists by
> publication date based on 260 and RDA 264, please read further.
>
> OR If you use varying kohafield mappings across your MARC frameworks. Say
> you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in
> framework B.
>
>
>
> Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306)
> is aimed to resolve the issue of having the copyrightdate in two MARC
> fields.
>
> It allows you to have multiple mappings per kohafield. So you can connect
> 260c and 264c to copyrightdate. Current Koha allowed you to add the second
> mapping already in the frameworks, but it silently ignores one of the two.
>
>
>
> In finishing this development however, I got stuck at the following
> question: Should Koha really allow varying kohafield mappings per
> framework? In the above example the multiple mappings feature should
> resolve the need of having a different assignment for copyrightdate between
> framework A and B. Both could simply have two mappings for copyrightdate.
>
> Although Koha more or less allows you to add kohafield assignments per
> framework via the MARC frameworks, it does not really support kohafields
> per framework. (The Koha to MARC mappings tool in Administration does
> change the mappings in Default and copies them to other frameworks.) We
> have GetMarcFromKohaField calls in the codebase that do not pass a
> framework code. And when we process search results or import records, we do
> not have a framework code either. So in those cases Koha just uses the
> kohafield mappings from the Default framework, although you might have
> specified another mapping in the associated framework of a search result.
>
>
>
> I would propose now to make the decision that we only use one set of
> kohafield mappings (those from Default), and that we do no longer allow
> changes to kohafield mappings in the other frameworks.
>
> The possibility of adding multiple mappings per kohafield hopefully
> removes most objections to that approach as illustrated in the frameworks A
> and B example.
>
>
>
> I submitted my changes so far on the Bugzilla report. If we agree on
> Default as the authoritative framework for these mappings, I will still add
> code to change GetMarcFromKohaField calls etc.
>
>
>
> If you have stringent reasons for maintaining varying kohafield mappings
> per framework and your need for them cannot be resolved with multiple
> mappings, please respond and provide information about the fields you are
> mapping differently across your frameworks.
>
>
>
> Any other feedback is welcome too.
>
>
>
> Thanks,
>
>
>
> Marcel
>
>
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] ES6 usage in the staff client

[Jesse]

BS, 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/
>>
>
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] ES6 usage in the staff client

[Jesse]

As part of my work with Preact (and previous work with React), I've been
unsure what to do about these libraries' enthusiasm for ES6.

If you're not familiar, ES6 (or ES2015) is a recent, major update to the
JavaScript standard, and brings in a number of improvements to the
language. Many of these make small parts of JS development a bit more
pleasant, but the most relevant addition is native class support.

These built-in classes have been embraced by a lot of modern JS libraries,
including Preact. The commonly accepted way to write code in this libraries
depends on support for classes, either from the browser itself or a
transpiler like Babel. To use Preact, we have two options:

  * Use ES6 classes. This will work in Firefox 45+ (which includes two ESR
releases), Chrome 42+, Edge and Safari 9 [1][2]. I believe this is a very
reasonable set of browsers, for the staff client.
  * Use a shim for ES3 support (see [3] for an example of how this might
work). This can be done, but locks us to an older and less-used way of
developing on Preact/React.

I strongly prefer the first option, but would like your feedback.

[1] http://kangax.github.io/compat-table/es6/#test-class (Check "show
obsolete platforms", and get ready for your browser to slow down.)
[2] http://caniuse.com/#feat=es6-class (This is pessimistic; FF has had
support since version 45.)
[3] https://github.com/developit/preact-in-es3/blob/master/index.js


-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] ReactJS license problems

[Jesse]

d them to him.  He does not treat the
> breadth of conditions for patent termination unrelated to any particular
> software under the Facebook BSD+Patents license which obviates assumptions
> about costs of replacing software relative to the costs of litigation.  He
> dismisses any alternative scenarios citing one particular unlikely case,
> however, the most likely scenarios are indirect from the breadth of
> termination conditions and outside the scope of anything which he has
> considered.  Any scenario for which there is an actual problem may be
> unlikely, however, if you or your organisation are in the midst of such a
> scenario the likelihood of its occurrence is moot for you or your
> organisation.
>
> Problems in patent disputes are often indirect as in the scenario
> described by Aaron Williamson which I had originally cited,
> https://github.com/facebook/react/issues/10191#issuecomment-316380810 .
> Starting from Aaron's example I could imagine some scenario which
> corresponds to what I am informed is the usual type of problem which is
> faced over patents, however, my alteration of Aaron's example may suffer
> in some detail from not being a lawyer. A university with a state mandate
> in law to pursue patents arising from government funded research could be
> be substituted for Cisco in Aaron's example.  An issue covered by a
> traditional patent, not one reading on software, could be the issue
> pursued against a Facebook subsidiary.  After terminating all patent
> licenses granted to the university under the Facebook BSD+Patents license,
> Facebook might not pursue a patent action over ReactJS use by the
> university especially where the use prior to termination would have been
> licensed.  Yet, the university's loss of any Facebook patent license to
> assert in defence may be the opportunity for a patent troll (holding
> patents without any product using them) to threaten the university over
> some patent reading on ReactJS.  The patent troll would know that the
> university would be likely to agree to pay protection money to license the
> patent held by the troll to avoid the cost of litigation especially
> without a Facebook patent license for the university to assert in defence.
>  The troll would also not have to risk any possible Facebook patents being
> asserted by the university to invalidate any claims in the patent which
> the troll would be asserting.  The goal of the patent troll is to obtain
> protection money without much risk of actually having to face the
> financial costs or other hazards of litigation.
>
> Even if GPLv3 license compatibility would not be a problem and even if
> almost all Koha users would never have even a traditional patent nor a
> mandate to pursue patents, we should not create potential burdens upon
> organisations which may be candidates for using Koha beyond the relatively
> simple obligations respecting free software.  Certainly, we should not
> create a burden which Aaron Williamson describes as "compliance requires a
> burdensome -- maybe impossible -- degree of diligence."
>
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> +1 212-674-3783
>
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Serious problem

[Jesse]

Is there some sort of pragma or option we could set on the database or
table to prevent this autooptimization?

On Sun, Sep 4, 2016, 18:20 David Cook  wrote:

> Glad to see someone else looking at this bug. We had this happen just the
> other day.
>
> Mark, I think the reset of auto_increment also happens after OPTIMIZE
> TABLE,
> if I recall correctly. Very annoying...
>
> Owen, you create a new entry in issues which gets an auto_id of 500. That
> bumps up the auto_increment to 501. However, if you move that entry into
> old_issues - with an id of 500 - then restart the MySQL server (it seems)
> or
> run OPTIMIZE TABLE issues, the auto_increment for issues is reset to 500.
> You try to check in that check out, and you get a software error, because
> there's already an entry with a primary key of 500 in the old_issues table.
>
> Not only is there a loss of history, but I'm pretty sure that newer issue
> stays in the issues table, because it can't be moved, and that'll likely
> have all sorts of flow on effects.
>
> Fun times!
>
> I noticed this happening for reserves as well last year or the year before
> I
> think. We've tried to mitigate it locally, since I don't really see a way
> of
> fixing this issue with the current Koha methodology of using
> deletedtables...
>
> David Cook
> Systems Librarian
> Prosentient Systems
> 72/330 Wattle St
> Ultimo, NSW 2007
> Australia
>
> Office: 02 9212 0899
> Direct: 02 8005 0595
>
>
> > -Original Message-
> > From: koha-devel-boun...@lists.koha-community.org [mailto:koha-devel-
> > boun...@lists.koha-community.org] On Behalf Of Mark Tompsett
> > Sent: Wednesday, 31 August 2016 11:42 PM
> > To: Owen Leonard 
> > Cc: Koha-devel 
> > Subject: Re: [Koha-devel] Serious problem
> >
> > Greetings,
> >
> > >> check out, check in, restart mysql server, check out, check in...
> > >> old_issues bug!
> >
> > > What exactly is the bug?
> >
> > Loss of history.
> > Unless you do this after the server restart:
> > use koha_library;
> > insert into issues (borrowernumber) values (1);
> > -- this will fill the gap, and should restore it.
> > actually, whatever the mysql is to set the auto_increment to
> > max(issue_id)+1 from old_issues would work too.
> >
> > 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] Introduce the use of Grunt or Gulp?

[Jesse]

One workaround for the Gulp/Grunt/DFSG issue would be to build a Debian
package and host it on the koha-community repo. I would be willing to do
this.

Unfortunately, all of the frontend build tools seem to either:
  a) have license issues preventing them from having an official Debian
package (Grunt, Gulp),
  b) not be popular enough to have a package or be viable (broccoli,
others) or
  c) have limitations in functionality that make them not worth the effort
(Jake).

I agree with Owen both that this is strongly needed and that it would be
doing complex enough tasks to make maintaining a separate, limited build
script for packaging/tarball installs untenable.

2016-02-26 14:10 GMT-07:00 Owen Leonard <oleon...@myacpl.org>:

> Are we at an impasse on this? I think the lack of *something* to
> manage front-end assets is making Koha less efficient to use and more
> difficult and error-prone to develop for.
>
>  -- Owen
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

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

[Jesse]

I really like this idea; it would help some longstanding performance issues
on the OPAC (and perhaps, eventually, the staff side). Even better, it
would make regeneration of the CSS from the LESS a bit more
straightforward, and allow us to remove the generated files from Git.
Eventually, it could also give a cleaner solution for some of the caching
issues we've hacked around.

It seems like the easiest way forward would be to minify/concatenate all of
the JS and CSS that is shown on every page (so we could just throw a link
to the output in doc-head-close). Thoughts?

2016-02-07 18:53 GMT-07:00 Owen Leonard <oleon...@myacpl.org>:

> I would very much like to start using some kind of build tool for
> front-end assets in Koha. The ones I've encountered are Grunt and
> Gulp:
>
> Grunt: http://gruntjs.com/
> Gulp: http://gulpjs.com/
>
> I have some experience with Grunt, and have heard good things about
> Gulp. Has anyone else used either in their non-Koha projects?
>
> Adopting them would introduce a little more complexity to the process
> of making client-side changes to Koha, and to be honest I'm not sure
> of the right way to incorporate the tools into our workflow.
>
> What I see as the advantages:
>
> - Automatic linting, minification, and concatenation of CSS and JS
> - Potentially, automatic compression of images and contruction of image
> sprites
> - Overall performance improvements from the above
>
> Disadvantages: A new process to learn for those wanting to contribute
> front-end modifications. A new set of dependencies for front-end
> developers (Node.js etc).
>
> If there is interest I'd be happy to submit a patch introducing the
> process to the OPAC as a demonstration.
>
>   -- 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/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] RFC: Circulation Rules Interface and Backend Revamp RFC

[Jesse]

It's a bit hard to parse out the changes in 5872, but I believe that the
main difference between this proposal and 8369/5872 are the non-tabular
interface and the new database structure.

Here's my main argument for a non-tabular interface: many of the circ
policies are common to an entire branch, category or itemtype, but the
current interface requires them to be duplicated for every combination that
needs new circ rules. It's very very difficult for a table to show the
per-policy inheritance that we need to untangle this mess; 5872 made an
effort, but I'd argue that with as complicated as the inheritance can be,
the grey-cell approach could become quite confusing rather quickly. The new
interface might need tuning, but I believe we need something different from
what we have now.

(By the way, if you have a system with very complicated issuingrules,
please post a dump on bug 15521! It'll be very useful for planning the
backend and interface.)

2016-01-08 2:17 GMT-07:00 Jonathan Druart <
jonathan.dru...@bugs.koha-community.org>:

> (continuing on devel only)
>
> That's good news :)
> We absolutely need a discussion here indeed, not to reproduce previous
> attempts who failed.
> For instance, (I have only 2 examples in mind) :
> - Simplify the DB structure: Bug 8369 - default_branch_circ_rule and
> default_circ_rules tables useless
> - Modify the display : Bug 5872 - Enhancements to circulation
> You can find on comment 27 a screencast to show you the interface
> suggested: http://screencast.com/t/4duT8KV6VjQ (Thanks Liz for that!)
>
> As I completely agree the current interface has show its limits, I
> personally think that the table is a good way to have an overview of
> the rules. What you suggest seems less easy to understand, especially
> for libraries using very complex circ rules.
>
> Cheers and good luck :)
> Jonathan
>
> 2016-01-07 20:12 GMT+00:00 Jesse <pianohac...@gmail.com>:
> > The backend and frontend of the circulation/policy rules in Koha have
> been
> > extended and stretched to the point where they cause a fair amount of
> > issues and frustration. Many librarians and developers are uncertain when
> > default rules are applied, and the very large number of possible settings
> > makes the interface and backend unwieldy.
> >
> > Full details for our intended solution can be found at the link at the
> > bottom of this email, but here's the gist:
> >
> > Instead of having one database row with all settings for a given
> > library/category/itemtype, allow each setting (checkout length, fine
> > amount, holds allowed, etc.) to be specified separately.
> > Rework the interface to more clearly show the specificity of
> > default/specific rules, and allow for this new database model.
> > Accomplish the above incrementally by gradually changing APIs.
> >
> >
> http://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC
> >
> > Any and all comments are appreciated. Development on this project has
> been
> > fully sponsored, and we are looking to start work later this year.
> > --
> > Jesse Weaver
> > ___
> > Koha mailing list  http://koha-community.org
> > k...@lists.katipo.co.nz
> > https://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/
>



-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Debugging in vim

[Jesse]

I've used it without running into pain with Komodo as well. What issues are
you running into?

2015-11-30 7:30 GMT-07:00 Julian Maurice <julian.maur...@biblibre.com>:

> I do it daily, it's a life changer! :)
>
> But everything seems ok in the wiki. What is the dependency hell you are
> talking about ?
>
> Le 30/11/2015 14:35, Barton Chittenden a écrit :
> > Hi, has anyone gotten debugging to work in vim, using the instructions
> here?
> >
> > http://wiki.koha-community.org/wiki/Debugging_in_VIM
> >
> > I tried it, and ran into dependency hell... If I remember
> > correctly, Komodo-PerlRemoteDebugging-4.4.1 didn't play nicely
> > with https://github.com/joonty/vdebug.
> >
> > If someone *has* gotten this working, I'd like to know how it was done,
> > so that I can update the wiki.
> >
> > Thanks,
> >
> > --Barton
> >
> >
> > ___
> > Koha-devel mailing list
> > Koha-devel@lists.koha-community.org
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
> >
>
>
> --
> Julian Maurice <julian.maur...@biblibre.com>
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

Re: [Koha-devel] Proposed "metadata" table for Koha

[Jesse]

If we do this, I very much vote for doing it the way Tomas is describing
(aka, storing entire chunks of metadata as blobs). Koha 2.2 had a
row-per-subfield structure kind of like what you're suggesting, and it
required a lot of monkeying around to accurately represent all the vagaries
and ordering of MARC subfields. It was also (from what I remember) quite a
disk hog.

2015-11-30 15:42 GMT-07:00 David Cook <dc...@prosentient.com.au>:

> Just to contradict myself a bit, it might be worth mentioning that Zebra
> will do a better job with ISSN and ISBN matching, as I think it normalizes
> those strings. That would be nicer than a regular string matching SQL query…
>
>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St, Ultimo, NSW 2007
>
>
>
> *From:* Tomas Cohen Arazi [mailto:tomasco...@gmail.com]
> *Sent:* Tuesday, 1 December 2015 1:20 AM
> *To:* David Cook <dc...@prosentient.com.au>
> *Cc:* koha-devel <koha-devel@lists.koha-community.org>
> *Subject:* Re: [Koha-devel] Proposed "metadata" table for Koha
>
>
>
>
>
>
>
> 2015-11-29 21:52 GMT-03:00 David Cook <dc...@prosentient.com.au>:
>
> Hi all:
>
>
>
> For those not following along at
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662, we’ve
> recently started talking about the possibility of adding a “metadata” table
> to Koha.
>
>
>
> The basic schema I have in mind would be something like: metadata.id,
> metadata.record_id, metadata.scheme, metadata.qualifier, metadata.value.
>
>
>
> The row would look like: 1, 1, marc21, 001, 123456789
>
>
>
> It might also be necessary to store “metadata.record_type” so as to know
> where metadata.record_id points. This obviously has a lot of disadvantages…
> redundant data between “metadata” rows, no database cascades via foreign
> keys, etc. However, it might be necessary in the short-term as a temporary
> measure.
>
>
>
> Of course, adding “yet another place” to store metadata might not seem
> like a great idea. We already store metadata in biblioitems.marcxml (and
> biblioitems.marc), Zebra, and other biblio/biblioitems/items relational
> database fields. Do we really need a new place to worry about data?
>
>
>
> I think we should have a metadata_record table storing the serialized
> metadata, and more needed information (basically the fields
> Koha::MetadataRecord has...) and let the fulltext engine do the job for
> accessing those values.
>
>
>
> The codebase is already too bloated trying to band-aid our "minimal" usage
> of the search engines' features. Of course, while trying to fix that we
> might find our search engine has problems and/or broken functionalities
> (zebra facets are so slow that are not cool). But we should definitely get
> rid of tons of code in favour of using the search engine more, and probably
> have QueryParser be the standard, having a driver for ES...
>
>
>
> --
>
> Tomás Cohen Arazi
>
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

Re: [Koha-devel] [Koha-patches] Bug 14407 - Limit web-based self-checkout to specific IP addresses

[Jesse]

(moving this discussion to koha-devel)

Koha currently just uses regular expressions to match against IP addresses
(see line 1040 or so in latest C4/Auth.pm). While this isn't terribly
elegant, it's at least simple; what additional benefits does
Net::IP::Match::XS bring? (It would also be a problematic dependency, given
that it's not currently a Debian package.)

2015-06-24 22:59 GMT-06:00 Nicholas van Rheede van Oudtshoorn 
vano...@gmail.com:

 Greetings everyone,

 As I'm still very much a perl newbie, I'd love to get some feedback on a
 patch I just pushed to bug 14407 (my own bug!) We use Self-Checkout here
 http://library.pbc.wa.edu.au/, with users just having to scan their
 barcode to take books out. Our OPAC is also live over the internet. That
 means that anyone who knows Koha, can access the self-checkout from off
 campus! This patch adds a preference allowing one to limit access to those
 pages to specific IP addresses or ranges. I've used  Net::IP::Match::XS to
 do the heavy lifting - is there another library that Koha already uses to
 do the same sort of thing?

 Thanks in advance,
 Nick
 Perth Bible College http://www.pbc.wa.edu.au/


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




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] We need Koha Naming Standards

[Jesse]

I've gone ahead and added them anyway, since we still have opac-shelves.pl
and C4:VirtualShelves hanging around.

2015-06-22 8:28 GMT-06:00 Kyle Hall kyle.m.h...@gmail.com:

 Excellent list Jonathan! I think You've summed up most if not all the
 terms that need clarifying. The only one I could possibly add is Lists, but
 I don't think anyone has called them virtual shelves in ages.

 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 )
 Mill Run Technology Solutions ( http://millruntech.com )

 On Fri, Jun 19, 2015 at 10:42 AM, Jonathan Druart 
 jonathan.dru...@biblibre.com wrote:

 I have created a page on the wiki for the terminology:
 http://wiki.koha-community.org/wiki/Terminology

 IMO what we need, most of all, is a consensus on how we want to see
 the Koha namespace organised.

 2015-06-19 15:35 GMT+01:00 Kyle Hall kyle.m.h...@gmail.com:
  It's been discussed a few times, but I think we need to formalize naming
  conventions when writing patches for Koha.
 
  The worse offenders are those things that we use many different names
 for
  both internally and externally. I think patrons/borrowers/members is the
  worst offender. List come to mind as well ( previously being virtual
 shelves
  ).
 
  I believe that our internal nomenclature should reflect our outward
  nomenclature. So if the staff and/or OPAC use the term patron we
 should be
  using the term patron in our code as well, especially for namespaces.
 
  What does everyone think?
 
  The more we hammer out now the easier it will be to vote on naming
 rules at
  the dev meeting.
 
  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 )
  Mill Run Technology Solutions ( http://millruntech.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/




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] We need Koha Naming Standards

[Jesse]

Definite +1 to this.

Should we also discuss adding this to the coding standards at the next
development meeting?

2015-06-19 8:43 GMT-06:00 Jonathan Druart jonathan.dru...@biblibre.com:

 The discussion started from bug 12598 comment 44.
 For instance, do we want Koha::Patron::Import or Koha::Import::Patron?

 2015-06-19 15:35 GMT+01:00 Kyle Hall kyle.m.h...@gmail.com:
  It's been discussed a few times, but I think we need to formalize naming
  conventions when writing patches for Koha.
 
  The worse offenders are those things that we use many different names for
  both internally and externally. I think patrons/borrowers/members is the
  worst offender. List come to mind as well ( previously being virtual
 shelves
  ).
 
  I believe that our internal nomenclature should reflect our outward
  nomenclature. So if the staff and/or OPAC use the term patron we
 should be
  using the term patron in our code as well, especially for namespaces.
 
  What does everyone think?
 
  The more we hammer out now the easier it will be to vote on naming rules
 at
  the dev meeting.
 
  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 )
  Mill Run Technology Solutions ( http://millruntech.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/




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

Re: [Koha-devel] Fwd: [CODE4LIB] marc4js - a node.js module for processing MARC data

[Jesse]

While this may not be as useful for the ES project, I am working on a
web-based MARC editor for Koha that may benefit from this work. How
difficult do you think it would be to use this module from client-side JS?

2015-03-26 2:15 GMT-06:00 Stefano Bargioni bargi...@pusc.it:

 Maybe this module can be useful in the ElasticSearch project...
 Stefano

 Begin forwarded message:

  From: Jiao, Dazhi dj...@iu.edu
  Subject: [CODE4LIB] marc4js - a node.js module for processing MARC data
  Date: 26 marzo 2015 05:03:38 CET
  To: code4...@listserv.nd.edu
  Reply-To: Code for Libraries code4...@listserv.nd.edu
 
  Hi,
 
  I wrote a Node.js module for handling MARC data while trying to learn
 MARC and Node.js. I borrowed a lot of ideas from marc4j, ruby-marc and
 pymarc.The module is open-source and hosted on github. If you are
 interested please check it out at https://github.com/jiaola/marc4js. It’s
 still at its early stage but I’d like to share it with the community and
 hopefully someone will find it useful. Feel free to submit a bug report,
 feature request or join the effort to make it better.
 
  Thanks!
 
  David
 
  --
  David Jiao
  System Analyst
  Enterprise Library Systems
  Indiana University
 
 

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




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Web services only of authenticated users [C4::Service]

[Jesse]

From a technical standpoint, the new Koha::Service class (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12272) does allow
authnotrequired to be passed. This doesn't resolve the API design problem,
but does solve part of the issue.

2015-03-04 15:26 GMT-07:00 Robin Sheat ro...@catalyst.net.nz:

 Zeno Tajoli schreef op wo 04-03-2015 om 18:20 [+0100]:
  today, working on do a metsearch for Opac,
  I have found that web service basic API (C4::Service)
  could be used only from authenticated users.

 There are plans afoot[0] to design a new restful API. The current one is
 very inconsistent (some parts use XML, some use JSON, etc.) and it needs
 a ground-up redesign. I'd jump in on that noting these sorts of things.
 What's there now is staff client focussed, but I think it's important to
 think about use cases for the OPAC too.

 [0] http://wiki.koha-community.org/wiki/New_REST_API_RFC
 --
 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/




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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 !DOCTYPE

[Jesse]

The shortened doctype looks odd, but is the new official recommendation for
HTML 5. Koha has changed to this for the OPAC and (I believe the staff
side).

2015-02-19 17:59 GMT-07:00 Paul A pau...@navalmarinearchive.com:

 doc-head-open.inc in 3.08 started by adding:

 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;

 3.18 just adds !DOCTYPE html -- which gives rise to errors in most
 verification processes (W3C etc).  Was there a reason to change this?
 (Can't find anything in bugs.)

 I'm playing with the Google mod_pagespeed in Apache 2.4, and adding the
 full DOCTYPE seems necessary. I haven't (yet) seen a downside to adding it
 back in.

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




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

Re: [Koha-devel] Fwd: Streamlining frontend development in Koha

[Jesse]

Indeed it is, thank you. Missed that on my first look at the code.

2014-11-25 1:30 GMT-07:00 Kallinen Pasi pasi.kalli...@pttk.fi:

 Reordering the substitutions is possible, using the standard po-file 
 c-format style:

 _(You have checked out %1$s books, %2$s of which are on hold).format(X, Y);



 --
 Ystävällisin terveisin

 Pasi Kallinen
 ICT-asiantuntija

 p. 050-408 6958
 pasi.kalli...@pttk.fi


 Pohjois-Karjalan Tietotekniikkakeskus Oy - www.pttk.fi

 
 From: koha-devel-boun...@lists.koha-community.org 
 [koha-devel-boun...@lists.koha-community.org] on behalf of Marc Véron 
 [ve...@veron.ch]
 Sent: Tuesday, November 25, 2014 10:09
 To: koha-devel@lists.koha-community.org
 Subject: Re: [Koha-devel] Fwd: Streamlining frontend development in Koha

 It would be great to have the possibility to reorder substitutions like
 proposed:

 _$(You have checked out $1 books, $2 of which are on hold, X, Y)

 Marc


 Am 24.11.2014 19:51, schrieb Jesse:
 Okay, thanks. That does seem to solve part of the problem. I notice
 that the code doesn't allow translators to reorder substitutions; is
 that not a major issue?

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



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

Re: [Koha-devel] Fwd: Streamlining frontend development in Koha

[Jesse]

Okay, thanks. That does seem to solve part of the problem. I notice
that the code doesn't allow translators to reorder substitutions; is
that not a major issue?

And that setup does work, but is a bit awkward. Do you have any strong
feelings as far as translating strings in JS outside .tt's and .inc's?
I could happily provide a proof-of-concept implementation.

2014-11-21 11:43 GMT-07:00 Tomas Cohen Arazi tomasco...@gmail.com:
 To avoid breaking phrases we currently use placeholders like here:

 (from koha-tmpl/intranet-tmpl/prog/en/includes/strings.inc)
 var RENEWALS_REMAINING = _(%s of %s renewals remaining);

 and then using like this:

 (from koha-tmpl/intranet-tmpl/prog/en/js/checkouts.js)
 RENEWALS_REMAINING.format( oObj.renewals_remaining, oObj.renewals_allowed )

 so we can have most texts in one single place (language-wise) and then the
 JS somewhere else.

 Regards
 Tomás



 El Fri Nov 21 2014 at 15:25:46, Jesse (pianohac...@gmail.com) escribió:

 I've been working on Rancor, a professional MARC editor for Koha
 sponsored by ByWater and DGI, for the past year or so. As Rancor has a
 lot more client-side complexity than many other parts of the staff
 interface, I've run into some major frustrations. I have a proposed
 solution for them, and would like feedback from both developers and
 translators:

 Let's rewrite Koha in GWT!

 But seriously. The issues come down to translation. Making cleanly
 translatable JavaScript frontend code using Koha's current system
 requires a lot of finagling and ugly syntax, especially for any
 complicated string. There are two problems.

 Problem One:

 For example, displaying You have checked out X books, Y of which are
 on hold is frustrating to impossible for either the developer or
 translator:

 _(You have checked out ) + X + _( books, ) + Y + _( of which are on
 hold)

 is easy for a developer to write, but gives the poor translator three
 separate strings to translate. The commonly given solution is to
 rewrite this as:

 _(Books checked out: ) + X + _(Books on hold) + Y

 which works, but is a bit less elegant, and not always realistic. An
 informal best practice that has some precedent in the OPAC and
 Datatables is to use named placeholders in the string:

 _(You have checked out __X__ books, __Y__ of which are on
 hold).replace(__X__, X).replace(__Y__, Y)

 This is good, but currently has to be rewritten for every translated
 string. I'd like to propose a syntax like the following:

 _$(You have checked out $1 books, $2 of which are on hold, X, Y)

 or

 _$(You have checked out $X books, $Y of which are on hold, {X: X, Y: Y})

 with a slight preference for the former. Either approach allows
 translators to reorder substitutions as needed. The exact details of
 the syntax are up for debate, but something that can be implemented
 once, thrown into staff-global.js, and used everywhere is the goal.

 Either approach would be treated the same as:

 _(You have checked out $1 books, $2 of which are on hold)

 for the purposes of generating .po's and creating translated templates
 from existing .po's.

 Problem two:

 Currently, for JavaScript code to contain translated strings, it must
 be placed within a .tt or .inc. This is a historic limitation of the
 translation scripts
 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4503). The
 stated reasons for not fixing it, besides the hairiness of the
 translation scripts, are that a) most JavaScript code has been moved
 to non-language specific directories and b) there are property-based
 translation systems available for JavaScript (see the
 datatables-strings.inc file for an example of how the latter works).

 Here are my reasons for disagreeing with these two points:

 a) Keeping most JavaScript code non-language-specific is a very
 laudable goal, both in terms of separation of concerns and
 deduplication of files in multi-language installs. I believe that the
 translation system should allow for translation of strings in .js
 files, however. Despite factoring out many modules and pieces of UI
 infrastructure using Require.JS, Rancor is currently sitting at ~1200
 lines of code that deal with showing error/informational messages to
 the user, all of which has to be in a .tt or .inc in the current
 system. This is untenable for any complex JS code.

 b) While this is more of a matter of taste, I do not like the
 properties-based translation system. For one thing, it punts the above
 problem to a solution like is used for datatables, with the
 translation strings in a .inc containing a single script and the
 rest of the code in a .js. Also, it introduces a layer of indirection
 that makes figuring out what is actually displayed to the user (and
 tracing where a given message came from) needlessly complicated.

 I believe that while the QA process should continue to encourage
 splitting out as much functionality as possible into
 non-language-specific JavaScript, _requiring_ it causes problems. I

[Koha-devel] Fwd: Streamlining frontend development in Koha

[Jesse]

I've been working on Rancor, a professional MARC editor for Koha
sponsored by ByWater and DGI, for the past year or so. As Rancor has a
lot more client-side complexity than many other parts of the staff
interface, I've run into some major frustrations. I have a proposed
solution for them, and would like feedback from both developers and
translators:

Let's rewrite Koha in GWT!

But seriously. The issues come down to translation. Making cleanly
translatable JavaScript frontend code using Koha's current system
requires a lot of finagling and ugly syntax, especially for any
complicated string. There are two problems.

Problem One:

For example, displaying You have checked out X books, Y of which are
on hold is frustrating to impossible for either the developer or
translator:

_(You have checked out ) + X + _( books, ) + Y + _( of which are on hold)

is easy for a developer to write, but gives the poor translator three
separate strings to translate. The commonly given solution is to
rewrite this as:

_(Books checked out: ) + X + _(Books on hold) + Y

which works, but is a bit less elegant, and not always realistic. An
informal best practice that has some precedent in the OPAC and
Datatables is to use named placeholders in the string:

_(You have checked out __X__ books, __Y__ of which are on
hold).replace(__X__, X).replace(__Y__, Y)

This is good, but currently has to be rewritten for every translated
string. I'd like to propose a syntax like the following:

_$(You have checked out $1 books, $2 of which are on hold, X, Y)

or

_$(You have checked out $X books, $Y of which are on hold, {X: X, Y: Y})

with a slight preference for the former. Either approach allows
translators to reorder substitutions as needed. The exact details of
the syntax are up for debate, but something that can be implemented
once, thrown into staff-global.js, and used everywhere is the goal.

Either approach would be treated the same as:

_(You have checked out $1 books, $2 of which are on hold)

for the purposes of generating .po's and creating translated templates
from existing .po's.

Problem two:

Currently, for JavaScript code to contain translated strings, it must
be placed within a .tt or .inc. This is a historic limitation of the
translation scripts
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4503). The
stated reasons for not fixing it, besides the hairiness of the
translation scripts, are that a) most JavaScript code has been moved
to non-language specific directories and b) there are property-based
translation systems available for JavaScript (see the
datatables-strings.inc file for an example of how the latter works).

Here are my reasons for disagreeing with these two points:

a) Keeping most JavaScript code non-language-specific is a very
laudable goal, both in terms of separation of concerns and
deduplication of files in multi-language installs. I believe that the
translation system should allow for translation of strings in .js
files, however. Despite factoring out many modules and pieces of UI
infrastructure using Require.JS, Rancor is currently sitting at ~1200
lines of code that deal with showing error/informational messages to
the user, all of which has to be in a .tt or .inc in the current
system. This is untenable for any complex JS code.

b) While this is more of a matter of taste, I do not like the
properties-based translation system. For one thing, it punts the above
problem to a solution like is used for datatables, with the
translation strings in a .inc containing a single script and the
rest of the code in a .js. Also, it introduces a layer of indirection
that makes figuring out what is actually displayed to the user (and
tracing where a given message came from) needlessly complicated.

I believe that while the QA process should continue to encourage
splitting out as much functionality as possible into
non-language-specific JavaScript, _requiring_ it causes problems. I
propose that the translation scripts be extended to process _() (and
possibly _$()) directives in .js files in language-specific .../js/
directories.

(Note: this is not a I think this is a fantastic idea that someone
else should work on proposal. I am willing and in fact eager to make
these changes. But it would affect many people, so I want your
thoughts first.)

--
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Fwd: Professional cataloger's interface

[Jesse]

I feel the professional cataloger's interface (codename Rancor) has gotten
to the point where we can start thinking about integrating it into mainline
Koha, and I've filed a bug (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11559) with
relevant information and a link to the codebase on Github.

For those unfamiliar with the project, Rancor is a project I am working on
for ByWater and a client of theirs. We're hoping to bring Koha a MARC
editor that is powerful and intuitive for professional catalogers, who are
poorly served by Koha's existing MARC editor.

It has most of the core editing functionality nailed down, with some final
refinements and improvements still needed to get it to production quality.
Please try it out, and put any questions or comments on the bug.

Thanks,
-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] biblio and biblioitems

[Jesse]

+1 to this idea. It would help simplify a lot of code, and make a lot of
future improvements easier.


On Fri, May 3, 2013 at 8:38 AM, Galen Charlton g...@esilibrary.com wrote:

 Hi,

 On Fri, May 3, 2013 at 6:20 AM, Mathieu Saby
 mathieu.s...@univ-rennes2.fr wrote:
  Thank you.
  So, just to know, do you think it would be
  1. - a total waste of time ?
  2. - a strange idea ?
  3. - a good idea (for performance and code maintenance) ?
  4. - harmful ?
 
  to merge the biblio and biblioitem tables ?

 My gut feeling is #3, but a lot of testing would be needed to avoid
 #4.  Possibly one way to reduce risk and improve testability would be
 to move columns over to biblio one at a time.

 Here are a couple additional thoughts if we undertake this:

 [1] We should decide whether we want to keep both bibilioitems.marc
 and biblioitems.marcxml.  I think we can get rid of the former.

 [2] Even if we merge the tables, I think we should still keep the
 marcxml column in its own table, e.g., one called biblio_metadata:

 CREATE TABLE biblio_metadata (
biblio_metadata_id INTEGER NOT NULL AUTO_INCREMENT; -- for the future!
biblionumber INTEGER,
metadata_type VARCHAR(10), -- for the future!
blob LONGTEXT NOT NULL,
-- and relevant FK contraints
 );

 The bits about slipping in multi-metadata-schema support aside, for
 many queries there's no reason to pull in largish XML columns.

 [3] We should see if we can drop some columns.  As a rule of thumb, I
 suggest that if a biblio/bilbioitems column isn't referred to in the
 code. any of the default MARC frameworks, or the SQL reports library,
 it's probably not being used.

 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/




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Active borrowers report

[Jesse]

Wow, that's an old report. Glad you got some use out of it, and found a way
to make it better!

On the other hand, should we consider promoting the use of the `statistics`
table? Though I've been out of the loop, I think it was easier to design
reports like this around. Spent many frustrating hours and LEFT JOINs
trying to twist the `issues` and `old_issues` tables into the output the
librarians asked for.

2012/1/9 Mike Hafen mdha...@tech.washk12.org

 Cool.  Though I would prefer Jesse Weaver get all/joint credit for it.  I
 really just changed his sql a bit.

 On Mon, Jan 9, 2012 at 2:31 PM, Liz Rea l...@nekls.org wrote:

 And you know what, that one isn't in the report library so I added it for
 you. :)

 You can see it here:
 http://wiki.koha-community.org/wiki/SQL_Reports_Library#Active_Patrons

 Thanks!

 Liz Rea
 l...@nekls.org




 On Jan 9, 2012, at 2:36 PM, Mike Hafen wrote:

  SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
 borrowernumber)
  FROM (
SELECT issuedate, borrowernumber FROM old_issues
   UNION ALL
SELECT issuedate, borrowernumber FROM issues
  ) AS all_issues
  LEFT JOIN borrowers USING (borrowernumber)
  GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode




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




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Notifications RFC

[Jesse]

2011/8/25 Elliott Davis tda...@uttyler.edu

 Hey Guys,

 ** **

 I have noticed of late that notifications is in quite a state of disarray.
 At my library we have had to resort to running queries from a script and
 manually sending out mail because notifications just don’t work in a usable
 way.  I am proposing an overhaul of the notifications system.  The only
 information I have to go on is what my library wants but since we are an
 academic library that may vary from what the vast majority of Koha wants.
 Before I made an official wiki for this RFC I wanted to get a general feel
 for how everyone felt about this.  I also wanted to see if someone or a
 group was willing to pitch in and help me out with some coding.

 ** **

 Essentially what I would like to do is model notifications to do the
 following: 

 ** **

 **1.   **Base notification rules on patron type, item type, and a new
 grouping I am hoping to write that I am calling the collection code

This sounds like it's a bit up in the air at the moment, but how does this
relate to the item collection codes that are already in Koha?

 

 2.   Define a frequency for notifications based on the previously
 stated groupings

 **3.   **Base the start time and end time for notifications on the due
 date rather than the checkout date

 ** **

 I am very open to other suggestions and I hope to get some.  I know that
 this idea is far from fully developed.

 ** **

 Best,

 ** **

 Elliott Davis

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


Everything else sounds good. The notifications backend is pretty good,
really, but the UI at least needs some love and updates.

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

Re: [Koha-devel] Perl scripts not ending in .pl

[Jesse]

There are reasons that these scripts lack that extension. koha-preferences
doesn't have the extension since it's a utility intended to be run from the
command line, as opposed to a cronjob or CGI script. Services just lack the
extension to distinguish them from user-facing CGI scripts. Besides, if
we're exposing APIs, it's nice to keep the underlying technology out of the
URL.

It's convention, not law, but it would be a bit of a pain to change it.

2011/7/31 Edgar Fuß e...@math.uni-bonn.de

  There's no reason for a perl program to end in .pl beyond convention
 Yes, of course.
 But if you have nearly all of the scripts ending in .pl and a
 fix-perl-path.PL that seems to suggest all the scripts do end in .pl, that's
 confusing.

 Let me elaborate on how this hit me:
 I was working for a fix to 6390, introducing a new syspref. Changing the
 syspref failed with ``internal server error'' (not the real one, the
 JavaScript popup).
 After hours of searching and tracing my web server, I found out that
 svc/config/systempreferences was not executed, but delivered, because a) I
 had configured my lighttpd to only execute .pl scripts and b) it had
 /usr/bin/perl, not /usr/pkg/bin/perl in it.

 So the problem was that this one script was different from the others.
 I was misled because I thought I had broken the setting of preferences with
 my patch, while really it never worked for me with this version of Koha. I
 just never tried since the upgrade.
 ___
 Koha-devel mailing list
 Koha-devel@lists.koha-community.org
 http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
 website : http://www.koha-community.org/
 git : http://git.koha-community.org/
 bugs : http://bugs.koha-community.org/




-- 
Jesse Weaver
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/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] Guidelines for Patch Acceptance/Rejection

[Jesse]

2010/11/10 Chris Cormack ch...@bigballofwax.co.nz

 I have a few extra rules for 3.4 also

 From here http://wiki.koha-community.org/wiki/Roadmap_to_3.4

 All patches should have at least 1 signoff before the Release Manager
 looks at them, (exceptions will be made for trivial patches).
 Preferably 2 signoffs, 1 from the QA manager and 1 from someone else.
 Although 1 from the QA manager will suffice.

 All patches should refer to a bug number

 Chris

 2010/11/11 Ian Walls ian.wa...@bywatersolutions.com:
  Everyone,
 
  While there can be no guarantees as to whether a patch will be committed
  into the Koha codebase, I think in practice there are several
 requirements.
   This email is an attempt to identify a few of them, and hopefully start
 a
  discussion about whether they are truly requirements, and what others
 could
  possibly be added.
  1.  The patch must do what it claims to do, in all commonly-supported
 Koha
  environments
  2.  The patch must not break existing functionality
  3.  The patch must apply to the current HEAD of the master branch of the
  code
  4.  The patch must follow the Coding Style Guidelines
  5.  The patch must be MARC-flavour agnostic
  6.  The patch must contain appropriate copyright information
  7.  If a database update is require, the patch must handle the update
 both
  for new installs and upgrades
  8.  If a new feature is added, the patch must include appropriate Help
  documentation
  What do people think of these requirements?  Are they reasonable?  Should
  there be more?  I understand that there may not be any set of
 requirements
  that's completely sufficient, but if we can identify as many as possible,
 it
  would make developers lives a bit easier, since we'd all have a better
 idea
  what is needed for our patches to be committable.
  Cheers,
 
  -Ian
  --
  Ian Walls
  Lead Development Specialist
  ByWater Solutions
  Phone # (888) 900-8944
  http://bywatersolutions.com
  ian.wa...@bywatersolutions.com
  Twitter: @sekjal
  ___
  Koha-devel mailing list
  Koha-devel@lists.koha-community.org
  http://lists.koha-community.org/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/


Question for Mr. 3.4 RM:

Is the procedure for dealing with DB revision numbers still the same? As far
as I remember from the 3.2 development days, the procedure was to patch
kohastructure.sql (or sysprefs.sql, or whatever), then add the update to the
end of updatedatabase.pl with a generic version number, like 3.01.00.XXX.
Patching kohastructure.pl was left to the RM when they applied the patch.

I had a crazy table on the wiki for a bit, but this seemed to work better.

That still the consensus?

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