Re: [Koha] How to limit number of copies?

[Marcel de Rooy]

Victor,

Please see bug 34146. That code does not use intranetuserjs.
It does use maxlength on the input as suggested by Owen.

Marcel


Van: Victor Barroso Oliveira 
Verzonden: donderdag 29 juni 2023 19:02
Aan: Marcel de Rooy 
Onderwerp: Re: [Koha] How to limit number of copies?

Hello,
The code inserted in "intranetuserjs" has not limited the number of copies.
I'm using version 21.05.21

Em qui., 29 de jun. de 2023 às 02:44, Marcel de Rooy 
mailto:m.de.r...@rijksmuseum.nl>> escreveu:
Bug 34146, patches attached.

Van: Koha 
mailto:koha-boun...@lists.katipo.co.nz>> 
namens George mailto:gwilli...@nekls.org>>
Verzonden: woensdag 28 juni 2023 16:07
Aan: koha@lists.katipo.co.nz<mailto:koha@lists.katipo.co.nz> 
mailto:koha@lists.katipo.co.nz>>
Onderwerp: Re: [Koha] How to limit number of copies?

Victor,

I'd recommend opening a bug on Bugzilla saying that a system preference
should be added to set the maximum number of copies that can be added to
a bibliographic record when someone uses the "Add multiple copies of
this item" button on additem.pl<http://additem.pl/>.

In the meantime, if you put this jQuery in the intranetuserJS system
preference, it will set the limit to 10 copies:

//Home > Cataloging > Edit TITLE > items
(cataloguing/additem.pl?biblionumber=n<http://additem.pl/?biblionumber=n>)
   //Limit the number of copies that can be added to a biblio using the
"Add multiple copies of this item" button
 $('#cat_additem
#number_of_copies').attr('type','number').attr('max','10');

And I'll add that jQuery to the jQuery library in just a few minutes.

George

On 6/27/2023 7:00 PM, 
koha-requ...@lists.katipo.co.nz<mailto:koha-requ...@lists.katipo.co.nz> wrote:
> Message: 3
> Date: Tue, 27 Jun 2023 15:36:17 -0300
> From: Victor Barroso Oliveiramailto:vbovic...@gmail.com>>
> To: Kohamailto:koha@lists.katipo.co.nz>>
> Subject: [Koha] How to limit number of copies?
> Message-ID:
>
> mailto:cacyxk604fqoudbduvn5pyvvkabrnxghwzuywswvjrr2vppq...@mail.gmail.com>>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello,
> In Koha it is possible to Add an instance or choose to "Add Multiple
> Copies" simultaneously to a record.
> So far so good. More. I had a situation where an employee mistakenly
> typed 800,000 copies for a record.
> As a result, when Koha started its automatic Indexing routine, it consumed
> all of the server's memory and crashed system access. When I tried to
> delete the 800,000 copies in batch, the system crashed. It took slow
> deletion from 5,000 to 5,000 to reach 800,000.
> Considering the aforementioned case, would any colleague know if we can
> limit the quantity in the option "Add Multiple Copies"?
> Thanks,
> Victor

--
George Williams
Pronouns: he/him
Next Search Catalog Coordinator
Send NEXT support e-mails to nexth...@nekls.org<mailto:nexth...@nekls.org>

NEKLS Office: 785-838-4090
Toll Free: 888-296-6963
Fax: 785-838-3989
Next After-Hours: 785-813-1356

For specific support issues, please use:
Next Catalog Support: nexth...@nekls.org<mailto:nexth...@nekls.org>
Courier Support: chandw...@nekls.org<mailto:chandw...@nekls.org>
Technology Support: t...@nekls.org<mailto:t...@nekls.org>

4317 W 6th St, Lawrence, KS, 66049
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2F=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cfcde12d806124b58f2f308db77e135ab%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638235581380934868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=uS9CqOaex9sSU3OWyPNR6t5JoBh0%2F5NJ1ph%2BaWQq1PM%3D=0<http://koha-community.org/><http://koha-community.org/>
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkoha=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cfcde12d806124b58f2f308db77e135ab%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638235581380934868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=c0SNzmie0ykXAzETpOEJubU1%2FixE5Y7nd1x%2F7X97lMg%3D=0<https://lists.katipo.co.nz/mailman/listinfo/koha><https://lists.katipo.co.nz/mailman/listinfo/koha>
___

Koha mailing list  http://koha-community.org<http://koha-community.org/>
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] How to limit number of copies?

[Marcel de Rooy]

Bug 34146, patches attached.

Van: Koha  namens George 
Verzonden: woensdag 28 juni 2023 16:07
Aan: koha@lists.katipo.co.nz 
Onderwerp: Re: [Koha] How to limit number of copies?

Victor,

I'd recommend opening a bug on Bugzilla saying that a system preference
should be added to set the maximum number of copies that can be added to
a bibliographic record when someone uses the "Add multiple copies of
this item" button on additem.pl.

In the meantime, if you put this jQuery in the intranetuserJS system
preference, it will set the limit to 10 copies:

//Home > Cataloging > Edit TITLE > items
(cataloguing/additem.pl?biblionumber=n)
   //Limit the number of copies that can be added to a biblio using the
"Add multiple copies of this item" button
 $('#cat_additem
#number_of_copies').attr('type','number').attr('max','10');

And I'll add that jQuery to the jQuery library in just a few minutes.

George

On 6/27/2023 7:00 PM, koha-requ...@lists.katipo.co.nz wrote:
> Message: 3
> Date: Tue, 27 Jun 2023 15:36:17 -0300
> From: Victor Barroso Oliveira
> To: Koha
> Subject: [Koha] How to limit number of copies?
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello,
> In Koha it is possible to Add an instance or choose to "Add Multiple
> Copies" simultaneously to a record.
> So far so good. More. I had a situation where an employee mistakenly
> typed 800,000 copies for a record.
> As a result, when Koha started its automatic Indexing routine, it consumed
> all of the server's memory and crashed system access. When I tried to
> delete the 800,000 copies in batch, the system crashed. It took slow
> deletion from 5,000 to 5,000 to reach 800,000.
> Considering the aforementioned case, would any colleague know if we can
> limit the quantity in the option "Add Multiple Copies"?
> Thanks,
> Victor

--
George Williams
Pronouns: he/him
Next Search Catalog Coordinator
Send NEXT support e-mails to nexth...@nekls.org

NEKLS Office: 785-838-4090
Toll Free: 888-296-6963
Fax: 785-838-3989
Next After-Hours: 785-813-1356

For specific support issues, please use:
Next Catalog Support: nexth...@nekls.org
Courier Support: chandw...@nekls.org
Technology Support: t...@nekls.org

4317 W 6th St, Lawrence, KS, 66049
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2F=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cfcde12d806124b58f2f308db77e135ab%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638235581380934868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=uS9CqOaex9sSU3OWyPNR6t5JoBh0%2F5NJ1ph%2BaWQq1PM%3D=0
Koha@lists.katipo.co.nz
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkoha=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cfcde12d806124b58f2f308db77e135ab%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638235581380934868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=c0SNzmie0ykXAzETpOEJubU1%2FixE5Y7nd1x%2F7X97lMg%3D=0
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Fwd: Dead Koha Resuscitation

[Marcel de Rooy]

> Almost everything worth permanently keeping in a typical Koha system is 
> stored in the database.
Just to be complete, dont forget your uploads in the clone folder. They are not 
stored in the database.

Marcel

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 22.11.00 Rosalie released

[Marcel de Rooy]

Great, Tomas! Congratulations. Thank you all.


Van: Koha  namens Tomas Cohen Arazi 

Verzonden: vrijdag 25 november 2022 19:36
Aan: koha 
Onderwerp: [Koha] Koha 22.11.00 Rosalie released

The Koha community is proud to announce the release of Koha 22.11.00.

Koha 22.11.00 is a major release, that comes with many new features.

It includes 13 new features, 351 enhancements, 3 security fixes, 551
bugfixes.

The full release notes are available here:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoha-community.org%2Fkoha-22-11-released%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C8dcf4cb1a27f42297a4408dacf1436b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638049982982095806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=vDqBSbnkd8rueTu%2BxAXvSYqJivy2%2BtHg4Y2UOyxHS%2BE%3Dreserved=0
>

Debian packages should be available soon

Best regards

--
Tomás Cohen Arazi
Theke Solutions 
(https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftheke.io%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C8dcf4cb1a27f42297a4408dacf1436b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638049982982095806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=gvlfjcBNoR5DwgN8Kw1%2FP8eNumNe0JEYjmS7G%2B5rBOA%3Dreserved=0)
✆ +54 9351 3513384
GPG: B2F3C15F
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C8dcf4cb1a27f42297a4408dacf1436b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638049982982095806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=aQ0F%2BczvwKcCDfuxjBIgkTElC4kWUQkh4L0R9sgU1N4%3Dreserved=0
Koha@lists.katipo.co.nz
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C8dcf4cb1a27f42297a4408dacf1436b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638049982982095806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5xRhZ1I2zOa%2FwIiKL%2FtlEF4ZhRI%2BPcLRR3djxNFQPRk%3Dreserved=0
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Background jobs stuck at "New" and can't be kick-started

[Marcel de Rooy]

There is a bug about json decoding iirc on Bugzilla.
Not sure if that got into 22.05 ?


Van: Koha  namens Aleisha Amohia 

Verzonden: donderdag 13 oktober 2022 21:34
Aan: koha@lists.katipo.co.nz 
Onderwerp: Re: [Koha] Background jobs stuck at "New" and can't be kick-started

Hi Marcel

There's a lot of this in worker-output.log:

Wide character in subroutine entry at
/usr/share/koha/lib/Koha/BackgroundJob.pm line 170.

Do you think that could be causing it to crash?

Nothing interesting in worker-error.log.

Thanks
Aleisha

On 13/10/22 18:35, Marcel de Rooy wrote:
> Hi Aleisha,
> What's in your logs? (worker log etc)
> Are the jobs started but do they actually crash on something ?
>
> Marcel
>
> 
> Van: Koha  namens Aleisha 
> Amohia
> Verzonden: woensdag 12 oktober 2022 23:23
> Aan: Koha
> Onderwerp: [Koha] Background jobs stuck at "New" and can't be kick-started
>
> Hi all,
>
> We're having some problems with background jobs and hoping we can get
> some advice.
>
> Running Koha 22.05.05, we have 25 background jobs stuck at New. Some are
> batch item record modifications, some are holds queue updates.
>
> I've tried restarted rabbit-mq and the koha-worker but it hasn't seemed
> to pick up the jobs, using these commands:
>
> $ sudo koha-worker --stop 
> $ sudo service rabbitmq-server stop
> $ sudo koha-worker --start 
>
> $ sudo koha-worker --stop 
> $ sudo service rabbitmq-server start
> $ sudo koha-worker --start 
>
> The biblionumbers and itemnumbers that the jobs are trying to affect are
> all legitimate records in the database.
>
> Would appreciate any ideas or suggestions from the community.
>
> --
> *Aleisha Amohia (she/her)*
> Koha Technical Lead
> *Catalyst IT - Expert Open Source Solutions*
>
> *Catalyst.Net Ltd - a Catalyst IT group company*
> Tel: +64 4 499 2267 
> |https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.catalyst.net.nz%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C47f4b72b05ef4c37f50a08daad5212d0%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012865277883202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yklaqYnigbj%2Fs%2BJsQ%2F6N5A42EePpsX4cBQvDP0%2F6XXU%3Dreserved=0
>   
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.catalyst.net.nz%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C47f4b72b05ef4c37f50a08daad5212d0%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012865277883202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yklaqYnigbj%2Fs%2BJsQ%2F6N5A42EePpsX4cBQvDP0%2F6XXU%3Dreserved=0>
>
> Catalyst Logo
>
> CONFIDENTIALITY NOTICE: This email is intended for the named recipients
> only. It may contain privileged, confidential or copyright information.
> If you are not the named recipient, any use, reliance upon, disclosure
> or copying of this email or its attachments is unauthorised. If you have
> received this email in error, please reply via email or call +64 4 499 2267.
> ___
>
> Koha mailing 
> listhttps://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C47f4b72b05ef4c37f50a08daad5212d0%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012865277883202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=rrARZ6tCXh9H4IRf%2BuCHqw2mOGAv1ZFgmnMWZ%2B%2BsgEo%3Dreserved=0
> Koha@lists.katipo.co.nz
> Unsubscribe:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C47f4b72b05ef4c37f50a08daad5212d0%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012865277883202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=bMRnV4NAG3h0SLqV3L1%2FSOFMXEMRMERtNXzAuKXPT50%3Dreserved=0
> ___
>
> Koha mailing 
> listhttps://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C47f4b72b05ef4c37f50a08daad5212d0%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012865277883202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=rrARZ6tCXh9H4IRf%2BuCHqw2mOGAv1ZFgmnMWZ%2B%2BsgEo%3Dreserved=0
> Koha@lists.katipo.co.nz
> Unsubscribe:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C47f4b72b05ef4c37f50a08daad5212d0%7C635b05eb66c748e1a94fb4b05a1b058b%

Re: [Koha] Background jobs stuck at "New" and can't be kick-started

[Marcel de Rooy]

Hi Aleisha,
What's in your logs? (worker log etc)
Are the jobs started but do they actually crash on something ?

Marcel


Van: Koha  namens Aleisha Amohia 

Verzonden: woensdag 12 oktober 2022 23:23
Aan: Koha 
Onderwerp: [Koha] Background jobs stuck at "New" and can't be kick-started

Hi all,

We're having some problems with background jobs and hoping we can get
some advice.

Running Koha 22.05.05, we have 25 background jobs stuck at New. Some are
batch item record modifications, some are holds queue updates.

I've tried restarted rabbit-mq and the koha-worker but it hasn't seemed
to pick up the jobs, using these commands:

$ sudo koha-worker --stop 
$ sudo service rabbitmq-server stop
$ sudo koha-worker --start 

$ sudo koha-worker --stop 
$ sudo service rabbitmq-server start
$ sudo koha-worker --start 

The biblionumbers and itemnumbers that the jobs are trying to affect are
all legitimate records in the database.

Would appreciate any ideas or suggestions from the community.

--
*Aleisha Amohia (she/her)*
Koha Technical Lead
*Catalyst IT - Expert Open Source Solutions*

*Catalyst.Net Ltd - a Catalyst IT group company*
Tel: +64 4 499 2267 | 
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.catalyst.net.nz%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ce3e402614f2e4e8045bd08daac981c00%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012066567572998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=blK62rU2SGaee9teTRc0vZCdRYun7%2FDmerIfJ%2F%2Boths%3Dreserved=0
 


Catalyst Logo

CONFIDENTIALITY NOTICE: This email is intended for the named recipients
only. It may contain privileged, confidential or copyright information.
If you are not the named recipient, any use, reliance upon, disclosure
or copying of this email or its attachments is unauthorised. If you have
received this email in error, please reply via email or call +64 4 499 2267.
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ce3e402614f2e4e8045bd08daac981c00%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012066567572998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mBgoNtEBFnStdfgF6Udfl5ylV%2BvS0UBhwjZJZrqOs38%3Dreserved=0
Koha@lists.katipo.co.nz
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ce3e402614f2e4e8045bd08daac981c00%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638012066567572998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=MY%2FgRfQlSOILFIpVuNkmkW%2BG8HIoPcGOs9eTYaA64c4%3Dreserved=0
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Edited authorities not updating in recently edited biblio records

[Marcel de Rooy]

Hi Elaine,
Please check bug 30883.
This fix is in: 22.11.00, 22.05.01, 21.11.10, 21.05.17
Questions here are: Are you using ElasticSearch? And does the number of touched 
biblio records exceed the merge limit ?

Regards,
Marcel


Van: Koha  namens Elaine Bradtke 

Verzonden: donderdag 25 augustus 2022 19:56
Aan: koha 
Onderwerp: [Koha] Edited authorities not updating in recently edited biblio 
records

I'm in the process of adding some 610 fields to catalogue records. These
are linked to existing authority records.  If I then edit the existing
authority record (usually to add (Musical group) to the 110) it doesn't
update 610 in the biblio record in which I just added the 610.  However, it
updates other records linked to that authority.
I think this is a timing issue; it will eventually update - possibly
related to 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2Fbugzilla3%2Fshow_bug.cgi%3Fid%3D25324data=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C45649f4e6aba4229fa8a08da86c35519%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970470763177952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=BLbZvRu6iJhzhwIrhXuJPxHGujSEYrOYr5JzvG4Pqz8%3Dreserved=0

Elaine Bradtke
VWML 

English Folk Dance and Song Society 

Cecil Sharp House, 2 Regent's Park Road, London NW1 7AY
Tel+44 (0) 20 7485 2206 (This number is for the English Folk Dance and
Song Society in London, England. If you wish to phone me personally, send
an e-mail first. I work off site)
--
Registered Company No. 297142
Charity Registered in England and Wales No. 305999
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C45649f4e6aba4229fa8a08da86c35519%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970470763177952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2BP2Fyb8jAAtCNsYzMJTGi%2Fcf8nZuCA2P5RrgC4t3Upc%3Dreserved=0
Koha@lists.katipo.co.nz
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C45649f4e6aba4229fa8a08da86c35519%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970470763177952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nvSiB2PnG%2Fm2U0LViJvOn%2BmPf03qiOJ5Vd1Jd%2BPs6rY%3Dreserved=0
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Fwd: FW: Recalls possible in KOHA

[Marcel de Rooy]

Please see bug 19532.
This feature is not yet part of Koha unfortunately.
Shortly, the QA/release team will be working on it again, hopefully getting
the feature in.

Marcel

PS Writing Koha is generally preferred on this mailing list 
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] OpacNavRight issue

[Marcel de Rooy]

Koha cache: memcached


Van: Koha  namens Mif 
Verzonden: dinsdag 21 december 2021 15:33
Aan: koha@lists.katipo.co.nz 
Onderwerp: Re: [Koha] OpacNavRight issue

I have Flushed the Cache, loaded in incognito and also on another device, the 
old content is still there.

Sent with 
[ProtonMail](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2Fdata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ca10664341a024e0c9d8608d9c48eec07%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756940415414322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=AK0ODIu%2F6XFCYVtrdatv%2Bmy3BbFptmuC619bdU%2BCBt8%3Dreserved=0)
 Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, December 21st, 2021 at 15:18, Mif  wrote:

> Hi, I have just updated to 21.11 and for some reason the OpacNavRight old 
> content cannot be deleted.
> I deleted every single item in custom html however the old content of 
> OpacNavRight is still there.
>
> Where can one manual delete the OpacNavRight content?
>
> Sent with 
> [ProtonMail](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2Fdata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ca10664341a024e0c9d8608d9c48eec07%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756940415424279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eLHggHF8N1e7v4jaeR%2BGnvpRZFWdxsJRPKL%2B16YkVU4%3Dreserved=0)
>  Secure Email.
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ca10664341a024e0c9d8608d9c48eec07%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756940415424279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0FxGyjU1w8llzehtU1tReJOGXehUDzXnXJCHsHggszc%3Dreserved=0
Koha@lists.katipo.co.nz
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Ca10664341a024e0c9d8608d9c48eec07%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756940415424279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vyjwWx4CCuTt4x6lZ7851j6%2B3ijCPLJd7o6A5aFzNsI%3Dreserved=0
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] OpacNavRight issue

[Marcel de Rooy]

Flush the cache ?


Van: Koha  namens Mif 
Verzonden: dinsdag 21 december 2021 15:18
Aan: koha@lists.katipo.co.nz 
Onderwerp: [Koha] OpacNavRight issue

Hi, I have just updated to 21.11 and for some reason the OpacNavRight old 
content cannot be deleted.
I deleted every single item in custom html however the old content of 
OpacNavRight is still there.

Where can one manual delete the OpacNavRight content?

Sent with 
[ProtonMail](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2Fdata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C89ae46de2e8847d0704908d9c48cf616%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756932010737239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=piKS8yKKUMIbfVWn5VS9acTxUNd%2BbM%2FMYQqyYCUVNjY%3Dreserved=0)
 Secure Email.
___

Koha mailing list  
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2Fdata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C89ae46de2e8847d0704908d9c48cf616%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756932010737239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5eIQRte5CKfpJ7%2B58oflxiJxL6deH9XPM3YWH8biMF0%3Dreserved=0
Koha@lists.katipo.co.nz
Unsubscribe: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkohadata=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C89ae46de2e8847d0704908d9c48cf616%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637756932010737239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=AX13AM%2FyG7xcy9bqncobVoqjLnxVGfhbN3FxszLd9z8%3Dreserved=0
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 21.11.00 released

[Marcel de Rooy]

Great work ! Thanks

Marcel

Op vr 26 nov. 2021 om 14:35 schreef Jonathan Druart <
jonathan.dru...@bugs.koha-community.org>:

> Hell everybody,
>
> Today is the day everybody is talking about: Koha 21.11.00 is out!
>
> It is with great pleasure that the Koha community announces the
> release of Koha 21.11, a major release of the Koha open source
> integrated library system.
>
> Read the full release notes here:
> https://koha-community.org/koha-21-11-released/
>
> The Debian packages for this new version will be available soon. Stay
> tuned!
>
> Note that I have built some statistics about the Koha development
> community, using git.
> I have published the charts on the wiki:
> https://wiki.koha-community.org/wiki/Development_Community_Statistics
>
> Cheers,
> Jonathan
> ___
>
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] Monthly Community Meeting

[Marcel de Rooy]

Semi annual voting on new roles too ?

Op wo 1 sep. 2021 om 16:31 schreef Renvoize, Martin <
martin.renvo...@ptfs-europe.com>:

> Hi all,
>
> We had our monthly general meeting today, as usual, hosted on IRC.
> Attendance has been very low for a while now and we mooted the idea of
> dropping it from our schedule and instead just having perhaps two meetings
> a year, one for Kohacon votes and a second for a broader annual general
> meeting should anyone want to raise any points in that formal setting.
>
> The next meeting is scheduled for 13th October 2021 at 1400 UTC where we
> will vote on the new reduced format.
>
> We're open to new idea's at any time and I'd be happy to try a video
> meeting or something if people would prefer. But at this point, we're not
> discussing much and I don't know if we're missing peoples views or people
> just don't have many or they have other ways of communicating with the
> community at large.
>
> Hope everyone is well,
>
> *Martin Renvoize, MPhys (Hons)*
>
> 
>
> Head of Development and Community Engagement
>
>
>
> *Phone:* +44 (0) 1483 378728
>
> *Mobile:* +44 (0) 7725 985 636
>
> *Email:* martin.renvo...@ptfs-europe.com
>
> www.ptfs-europe.com
>
>
> *Sign up for our newsletters here  or by
> scanning the QR code*
>
>
>
> Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30
>
> The information contained in this email message may be privileged,
> confidential and protected from disclosure. If you are not the intended
> recipient, any dissemination, distribution or copying is strictly
> prohibited. If you think that you have received this email message in
> error, please email the sender at i...@ptfs-europe.com
> ___
> Koha-devel mailing list
> koha-de...@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Fwd: Office365 and Koha selfregistration verification mails

[Marcel de Rooy]

s/Thread/Threat/

-- Forwarded message -
Van: Marcel de Rooy 
Date: do 27 aug. 2020 om 08:26
Subject: Office365 and Koha selfregistration verification mails
To: Koha 


FYI

The Office365 Advanced Thread Protection feature rewrites URLs and verifies
them when you click on them. When you try to register in Koha with an
Office365 email address, you will have a problem.

This has a nasty side-effect on selfregistration mails when you enabled
verification mails.
What happens, is: when Office365 verifies the link, the selfregistration is
completed and Office365 receives the credentials. The user actually does a
second call, the token is no longer found and he receives a failure
message. The Koha verification process is effectively sabotaged.

Note that you could add the Koha server domain as a do-not-rewrite URL in
the Office365 ATP setup somewhere..

Marcel
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Office365 and Koha selfregistration verification mails

[Marcel de Rooy]

FYI

The Office365 Advanced Thread Protection feature rewrites URLs and verifies
them when you click on them. When you try to register in Koha with an
Office365 email address, you will have a problem.

This has a nasty side-effect on selfregistration mails when you enabled
verification mails.
What happens, is: when Office365 verifies the link, the selfregistration is
completed and Office365 receives the credentials. The user actually does a
second call, the token is no longer found and he receives a failure
message. The Koha verification process is effectively sabotaged.

Note that you could add the Koha server domain as a do-not-rewrite URL in
the Office365 ATP setup somewhere..

Marcel
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Time slots for hold pickups

[Marcel de Rooy]

Good question. We would definitely be interested too in such functionality.

Marcel
Rijksmuseum

>
>
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] invalid marcxml

[Marcel de Rooy]

When you open and save a record again in Koha having patch 21708, the MARC
record will be fixed.
There is no conversion tool. You could open up a new report for that?
Sponsor its development?
Running touch_all_biblios will not do the job, as far as I can see.

Op do 14 mei 2020 om 18:27 schreef tuxflow.de :

> Ah, wonderful, very nice. Do existing entries need to be repaired?
>
> Or is there a converter? Thanks for the info!
>
> Am 14.05.20 um 13:28 schrieb Marcel de Rooy:
> > Please have a look at bug 21708.
> >
> > Op do 14 mei 2020 om 12:52 schreef :
> >
> >> Hi Joy,
> >>
> >> there is no direct error message from Koha, the error is only in the
> >> data structure. We only noticed this error because we're sending the
> >> data to a company so that it can be entered into the Discovery Service
> >> (search engine). This company pointed us to the wrong data structure. We
> >> need the corrected data to fully set up the Discovery Service.
> >>
> >> Koha-Version:   18.11.04.000
> >>
> >> greetings,
> >> tunix
> >>
> >> Am 13.05.20 um 19:41 schrieb Joy Nelson:
> >>> Hello-
> >>> Can you elaborate a bit more on this?  Is the order of the tags causing
> >>> errors in Koha?  Or is it just 'wrong' per the standard?
> >>>
> >>> I am unable to recreate the order you show in your example via the
> basic
> >>> editor or the advanced cataloging editor.  Can you explain what your
> >>> process is that creates this order?  Also what version of Koha are you
> >>> using currently?
> >>>
> >>> Thanks
> >>> joy
> >>>
> >>>
> >>> On Wed, May 13, 2020 at 10:25 AM  wrote:
> >>>
> >>>> We have a problem with our MARCXML data in KOHA. The order of the
> fields
> >>>> must be changed for many records. The problem affects all records that
> >>>> are newly created or changed by us. All  elements must
> appear
> >>>> after the  elements. So far the  element with
> >>>> the unique ID of the record (MARC field 999 $c) is placed before the
> >>>>  elements. The wrong order violates the MARCXML
> >> guidelines.
> >>>>
> >>>>
> >>>> before editing:
> >>>>
> >>>> 00996xxx x22002417x 4200
> >>>> 23330
> >>>> DE-1278
> >>>> t|
> >>>> 161220s2002 xxu|  00| 0 ger
> >>>> d
> >>>> 
> >>>> 3-89012-956-0
> >>>> 51,00 
> >>>> 
> >>>>
> >>>> after editing:
> >>>>
> >>>> 01059xxx x2200265x 4200
> >>>> 
> >>>> 9911
> >>>> 9911
> >>>> 
> >>>> 23330
> >>>> DE-1278
> >>>> 20190604142304.0
> >>>> t|
> >>>> 161220s2002 xxu|  00| 0 ger
> >>>> d
> >>>> 
> >>>> 3-89012-956-0
> >>>> 51,00 
> >>>> 
> >>>> ___
> >>>>
> >>>> Koha mailing list  http://koha-community.org
> >>>> Koha@lists.katipo.co.nz
> >>>> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> >>>>
> >>>
> >>>
> >>
> >> --
> >> tuxflow.de, das andere Hosting!
> >> ___
> >>
> >> Koha mailing list  http://koha-community.org
> >> Koha@lists.katipo.co.nz
> >> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> >>
> >
>
> ___
>
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] invalid marcxml

[Marcel de Rooy]

Please have a look at bug 21708.

Op do 14 mei 2020 om 12:52 schreef :

> Hi Joy,
>
> there is no direct error message from Koha, the error is only in the
> data structure. We only noticed this error because we're sending the
> data to a company so that it can be entered into the Discovery Service
> (search engine). This company pointed us to the wrong data structure. We
> need the corrected data to fully set up the Discovery Service.
>
> Koha-Version:   18.11.04.000
>
> greetings,
> tunix
>
> Am 13.05.20 um 19:41 schrieb Joy Nelson:
> > Hello-
> > Can you elaborate a bit more on this?  Is the order of the tags causing
> > errors in Koha?  Or is it just 'wrong' per the standard?
> >
> > I am unable to recreate the order you show in your example via the basic
> > editor or the advanced cataloging editor.  Can you explain what your
> > process is that creates this order?  Also what version of Koha are you
> > using currently?
> >
> > Thanks
> > joy
> >
> >
> > On Wed, May 13, 2020 at 10:25 AM  wrote:
> >
> >> We have a problem with our MARCXML data in KOHA. The order of the fields
> >> must be changed for many records. The problem affects all records that
> >> are newly created or changed by us. All  elements must appear
> >> after the  elements. So far the  element with
> >> the unique ID of the record (MARC field 999 $c) is placed before the
> >>  elements. The wrong order violates the MARCXML
> guidelines.
> >>
> >>
> >> before editing:
> >>
> >> 00996xxx x22002417x 4200
> >> 23330
> >> DE-1278
> >> t|
> >> 161220s2002 xxu|  00| 0 ger
> >> d
> >> 
> >> 3-89012-956-0
> >> 51,00 
> >> 
> >>
> >> after editing:
> >>
> >> 01059xxx x2200265x 4200
> >> 
> >> 9911
> >> 9911
> >> 
> >> 23330
> >> DE-1278
> >> 20190604142304.0
> >> t|
> >> 161220s2002 xxu|  00| 0 ger
> >> d
> >> 
> >> 3-89012-956-0
> >> 51,00 
> >> 
> >> ___
> >>
> >> Koha mailing list  http://koha-community.org
> >> Koha@lists.katipo.co.nz
> >> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> >>
> >
> >
>
> --
> tuxflow.de, das andere Hosting!
> ___
>
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Zero padding callnumber

[Marcel de Rooy]

Hi all,
Does anyone of you have experience with zero padding callnumbers in Koha?
We have shelves like 1, 10, 100 and 1000. And reports are always
problematic since 10 is between 1 and 2, etc.
So we want to zero padd to 0001, 0010, 0100 and 1000.
Since we will not adjust older hand written labels on books, they will
still list 1, 10, 100, etc.

Searching for the older callnumbers will no longer work after renumbering.
(Unless we leave the old callnumber in the record too, or make Koha's
search a bit wiser somehow.)

If you did something similar, did you encounter other things to take into
account?

Thanks,
Marcel de Rooy
Rijksmuseum Research Library
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Fwd: FW: Signoff request for bug 21190 [GDPR logging]

[Marcel de Rooy]

See my request below. Unfortunately, it was not accepted by the mailing
list due to added company signatures (with attachment).
So here is another try.

Marcel

-- Forwarded message -
Van: Marcel de Rooy 
Date: do 30 jan. 2020 om 09:04
Subject: FW: Signoff request for bug 21190 [GDPR logging]
To: rooy.d...@gmail.com 

*Van:* Marcel de Rooy
*Verzonden:* woensdag 29 januari 2020 14:23
*Aan:* koha ml 
*Onderwerp:* Signoff request for bug 21190 [GDPR logging]



Hi,

See bug 21190.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21190

GDPR: Log successful/unsuccessful login attempts [part 1]



Some people asked for it. I wrote something. I do not really need it
myself. I waited three months, but to no avail.

This is my last resort ;) If you are interested in such changes, please
test and signoff.

If no one is, I will not keep waiting but just happily close the report.



Thanks,

Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Z3950 search results

[Marcel de Rooy]

Hi all,

Do you miss the direct buttons for Card and MARC preview too in the Z3950 
search results table in recent Koha versions? Now you need to open the Actions 
menu first: so you need two clicks.
If you have any feedback on this topic, please add your comment on bug 23302.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23302

Thanks,
Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] Koha 19.05.00 Released

[Marcel de Rooy]

Great, Nick. Congrats.

Please correct the link to the release notes btw.

https://koha-community.org/koha-19-05-release/


Marcel


Van: koha-devel-boun...@lists.koha-community.org 
 namens Joy Nelson 

Verzonden: donderdag 30 mei 2019 18:10
Aan: Lucas Gass
CC: Koha; Koha Devel
Onderwerp: Re: [Koha-devel] [Koha] Koha 19.05.00 Released

Great work Nick!!

On Thu, May 30, 2019 at 11:00 AM Lucas Gass 
mailto:lu...@bywatersolutions.com>> wrote:
Great job Nick!!!

On Thu, May 30, 2019 at 9:53 AM Nick Clemens 
mailto:n...@bywatersolutions.com>>
wrote:

> Hello everybody,
>
> It is with great pleasure that the Koha community announces the release of
> Koha 19.05, a major release of the Koha open source integrated library
> system.
>
> This release (as always) is the work of many librarians, developers, and
> community members who donate their time and effort to the project. Their
> contributions help shape the release, and the project going forward. None
> of this would be possible without them, and my sincere thanks goes out to
> everyone who had a hand in the project
>
> Extra thanks to all who helped me with this release, and with getting here
> to be the release manager for this version. I am so lucky to work with such
> a great team on a wonderful project and look forward to helping make Koha
> better on each release. Excelsior!
>
> Read the full release notes here:
> https://koha-community.org/koha-18-11-release/
>
> Debian packages will be available shortly, if you are following a suite you
> will
> automatically upgrade to the next branch with this release, more info here:
>
> https://wiki.koha-community.org/wiki/Koha_on_Debian#Follow_a_suite:_stable.2C_oldstable_.E2.80.A6
>
> Thank you all,
> Nick (kidclamp)
>
> --
> Nick Clemens
> ByWater Solutions
> bywatersolutions.com
> Phone: (888) 900-8944
> Pronouns: (he/him/his)
> Timezone: Eastern
> ___
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


--
Joy Nelson
President, Koha Division

ByWater Solutions
Support and Consulting for Open Source Software
Phone/Fax (888)900-8944
What is Koha? 

[https://docs.google.com/uc?export=download=1jnnA_xzxbRZWnIBkuEE-9Xvqe2eJUkLo=0B5Y57KiwL9IEYm90eVZLVE9oTTN4aWJzRVUrZVJhK3lLaXlvPQ]
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] a warm thank you and heartfelt congratulations

[Marcel de Rooy]

Thanks Gaetan, and success.


Marcel



Van: Koha  namens Gaetan Boisson 

Verzonden: vrijdag 27 juli 2018 10:32
Aan: Koha
Onderwerp: [Koha] a warm thank you and heartfelt congratulations

Hello community,

some of you already know it, today is my last day at BibLibre as a
project manager.

I want to send a big thank you to the whole community, this has been an
awesome experience, both on the professional front and the human one. I
give great importance to nurturing human relations and treating them as
the single most important thing we have, and i feel this community
definitely shares this value. Please keep being the same open minded and
positive people i have met!

I also really want to congratulate the whole community for its efforts
and involvement in this project. Koha really is an impressive endeavor,
but it's also a massively successful one. Of course that is all thanks
to your incredible energy, your amazing skills and your unbreakable will
to make things work.

I won't be too far and maybe we'll be in touch again! I believe people
who attended the hackfest in Marseille know the way to the bar pretty
well by now and will find it without me. In fact i will certainly be the
one missing these moments the most! Meeting you at the hackfests and
kohacons has probably been the best part of my experience here.

A few words about what i will be doing from now on: as a couple of you
might know, i have been studying Indonesian music for almost 14 years
now, for fun. I have applied for the Indonesian government's Darmasiswa
academic program, and am leaving there to study music, and more
specifically shadow puppet theater (wayang kulit). Good things ahead!

I hope to meet you again soon, somewhere else than in a bar in Marseille!

--
Gaetan Boisson
Chef de projet bibliothécaire
BibLibre
+33(0)6 52 42 51 29
108 rue Breteuil 13006 Marseille
gaetan.bois...@biblibre.com

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] "run_safe_xmlstarlet: command not found" after upgrade to 16.05.19.000

[Marcel de Rooy]

Mason,
You are missing something here in 16.05.19.
git grep run_safe_xmlstarlet
debian/scripts/koha-plack:PLACK_MAX_REQUESTS=$(run_safe_xmlstarlet 
$instancename plack_max_requests)
debian/scripts/koha-plack:PLACK_WORKERS=$(run_safe_xmlstarlet $instancename 
plack_workers)
The routine should be in koha-functions.sh.

Marcel

-Oorspronkelijk bericht-
Van: Marcel de Rooy 
Verzonden: donderdag 25 januari 2018 08:30
Aan: koha ml <koha@lists.katipo.co.nz>
Onderwerp: RE: [Koha] "run_safe_xmlstarlet: command not found" after upgrade to 
16.05.19.000

This is a routine in debian/scripts/koha-functions.sh Make sure that you have 
the correct koha-functions.sh in the right location (usr/share/koha/bin)

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Alex Shepherd
Verzonden: woensdag 24 januari 2018 21:27
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] "run_safe_xmlstarlet: command not found" after upgrade to 
16.05.19.000

Hi Team,

I’ve just done an upgrade to my koha systems to 16.05.19.000, but after the 
upgrade I was getting “Service Unavailable” messages.

I tracked it back to plack not starting.

For now I’ve disabled plack on all the instances and restarted apache and 
they’re all working again, but performance will be less…

Here is the error I see:  

root@koha:/usr/sbin# koha-plack --start  bbs
/usr/sbin/koha-plack: line 77: run_safe_xmlstarlet: command not found

Any suggestions?

Regards

Alex Shepherd

p: +64-7-829 4441
m: +64-21-64
e: kiwi64...@gmail.com

___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] "run_safe_xmlstarlet: command not found" after upgrade to 16.05.19.000

[Marcel de Rooy]

This is a routine in debian/scripts/koha-functions.sh
Make sure that you have the correct koha-functions.sh in the right location 
(usr/share/koha/bin)

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Alex Shepherd
Verzonden: woensdag 24 januari 2018 21:27
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] "run_safe_xmlstarlet: command not found" after upgrade to 
16.05.19.000

Hi Team,

I’ve just done an upgrade to my koha systems to 16.05.19.000, but after the 
upgrade I was getting “Service Unavailable” messages.

I tracked it back to plack not starting.

For now I’ve disabled plack on all the instances and restarted apache and 
they’re all working again, but performance will be less…

Here is the error I see:  

root@koha:/usr/sbin# koha-plack --start  bbs
/usr/sbin/koha-plack: line 77: run_safe_xmlstarlet: command not found

Any suggestions?

Regards

Alex Shepherd

p: +64-7-829 4441
m: +64-21-64
e: kiwi64...@gmail.com

___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 17.11.00 released

[Marcel de Rooy]

Great !

Congratulations, Jonathan and thx for your work.

Marcel


Van: Koha  namens Barton Chittenden 

Verzonden: dinsdag 28 november 2017 21:09
Aan: Hugo Agud
CC: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] Koha 17.11.00 released

w00t!

Congratulations Jonathan, and thanks for your hard work as RM.

(and kudos to QA team, dev and, documentation team of course)

--Barton

2017-11-28 14:10 GMT-05:00 Hugo Agud :

> Congratulations!!
>
> 2017-11-28 20:08 GMT+01:00 Tomas Cohen Arazi :
>
> > Congraats!
> >
> > El mar., 28 nov. 2017 a las 16:08, Jonathan Druart (<
> > jonathan.dru...@bugs.koha-community.org>) escribió:
> >
> > > Hello everybody,
> > >
> > > It is with great pleasure that the Koha community announces the release
> > of
> > > Koha 17.11, a major release of the Koha open source integrated library
> > > system.
> > >
> > > Read the full release notes here:
> > > https://koha-community.org/koha-17-11-released/
> > >
> > > The Debian packages for this new version will be available soon. Stay
> > > tuned!
> > >
> > > Cheers,
> > > Jonathan
> > > ___
> > > Koha mailing list  http://koha-community.org
> > > Koha@lists.katipo.co.nz
> > > https://lists.katipo.co.nz/mailman/listinfo/koha
> > >
> > --
> > Tomás Cohen Arazi
> > Theke Solutions (https://theke.io )
> > ✆ +54 9351 3513384
> > GPG: B2F3C15F
> > ___
> > Koha mailing list  http://koha-community.org
> > Koha@lists.katipo.co.nz
> > https://lists.katipo.co.nz/mailman/listinfo/koha
> >
>
>
>
> --
>
> *Hugo Agud - Orex Digital *
>
> *www.orex.es *
>
>
> [image: www.orex.es/koha] <
> http://www.orex.es/koha>
>[image: www.orex.es/vufind] 
> 
>
>
> Directo
>
> Calle Sant Joaquin,117, 2º-3ª · 08922 Santa Coloma de Gramanet - Tel: 933
> 856 138   ha...@orex.es · http://www.orex.es/
>
>
>
> No imprima este mensaje a no ser que sea necesario. Una tonelada de papel
> implica la tala de 15 árboles y el consumo de 250.000 litros de agua.
>
>
>
> Aviso de confidencialidad
> Este mensaje contiene información que puede ser CONFIDENCIAL y/o de USO
> RESTRINGIDO. Si usted no es el receptor deseado del mensaje (ni
> está autorizado a recibirlo por el remitente), no está autorizado a copiar,
> reenviar o divulgar el mensaje o su contenido. Si ha recibido este mensaje
> por error, por favor, notifíquenoslo inmediatamente y bórrelo de su
> sistema.
> ___
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Fwd: Inventory "problem" column definitions

[Marcel de Rooy]

Caroline,

Bug 14399 made some changes in this respect, but it seems not to have been 
backported to 16.05 (yet).

Although bug 12913 was backported. (Check your 16.05 version.)

One of the patches of 14399 says:

Problem status 'missingitem' is no longer used; the missing items are marked as 
'not_scanned'. Two additional statuses are: no_barcode and checkedout.

The change item status was confusing too. And bug 12913/14399 also made some 
changes in that respect.


Marcel



Van: Caroline Cyr-La-Rose <caroline.cyr-la-r...@inlibro.com>
Verzonden: dinsdag 31 oktober 2017 14:07
Aan: Marcel de Rooy; koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] Fwd: Inventory "problem" column definitions


16.05

On 10/31/2017 09:03 AM, Marcel de Rooy wrote:

Which version are you using ?


Van: Koha 
<koha-boun...@lists.katipo.co.nz><mailto:koha-boun...@lists.katipo.co.nz> 
namens Caroline Cyr-La-Rose 
<caroline.cyr-la-r...@inlibro.com><mailto:caroline.cyr-la-r...@inlibro.com>
Verzonden: vrijdag 27 oktober 2017 01:20:50
Aan: koha@lists.katipo.co.nz<mailto:koha@lists.katipo.co.nz>
Onderwerp: [Koha] Fwd: Inventory "problem" column definitions

Hello all,

I'm trying to figure out what the "problems" in my inventory output
mean. I'm using the barcode file input and the CSV output with Koha
16.05. I extrapolated some definitions, but I can't figure out "item not
scanned" and "change item status". Please don't hesitate to correct my
definitions if they are wrong!

  * missing item: item is in the database, but not in the barcode file
  * barcode not found: barcode is not in the database
  * wrong place: item should be in another location
  * item not scanned: item is in the database, but not in the barcode
file (what is the difference between this and "missing item"?)
  * change item status: ??

Are there other "problems" other than these five?

I will make sure to add the definitions to the wiki, since they are not
there nor in the manual.

Thanks everybody!


Caroline Cyr La Rose, MLIS
Head of training and support, inLibro
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Fwd: Inventory "problem" column definitions

[Marcel de Rooy]

Which version are you using ?


Van: Koha  namens Caroline Cyr-La-Rose 

Verzonden: vrijdag 27 oktober 2017 01:20:50
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Fwd: Inventory "problem" column definitions

Hello all,

I'm trying to figure out what the "problems" in my inventory output
mean. I'm using the barcode file input and the CSV output with Koha
16.05. I extrapolated some definitions, but I can't figure out "item not
scanned" and "change item status". Please don't hesitate to correct my
definitions if they are wrong!

  * missing item: item is in the database, but not in the barcode file
  * barcode not found: barcode is not in the database
  * wrong place: item should be in another location
  * item not scanned: item is in the database, but not in the barcode
file (what is the difference between this and "missing item"?)
  * change item status: ??

Are there other "problems" other than these five?

I will make sure to add the definitions to the wiki, since they are not
there nor in the manual.

Thanks everybody!


Caroline Cyr La Rose, MLIS
Head of training and support, inLibro
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Salvaging data before using DBMS auto increment fix

[Marcel de Rooy]

Hmm. You need to have room in the deleted range to do that of course..

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Marcel de Rooy
Verzonden: maandag 23 oktober 2017 14:43
Aan: Koha list <koha@lists.katipo.co.nz>
Onderwerp: Re: [Koha] Salvaging data before using DBMS auto increment fix

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Pedro,
Personally I would delete the 19 old ones. Your option 2. Easiest, no big data 
loss..
In contrast with your option 3 you could also renumber the 19 old issues in the 
deleted table. The autoincr will be reset when you add another record and you 
made room for the 19 new ones. It seems safer to me than touching the active 
issues.
There is a bug about a script for this, but it got into In Discussion..

Marcel


-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Pedro Amorim
Verzonden: maandag 23 oktober 2017 14:13
Aan: Koha list <koha@lists.katipo.co.nz>
Onderwerp: [Koha] Salvaging data before using DBMS auto increment fix

Hello all,

I want to implement
https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix on our instance, 
however from my understanding this will only prevent the problem from happening 
in the future, it will not fix the current corrupted data.

I happen to have 19 ids that exist on both issues and old_issues and would like 
to the clean-up before going further. However, I'm not sure how to
proceed:

1) Remove the 19 ids from the *issues* table and implement the fix.
Downside is the data of those 19 issues would be lost and it would be as if 
those check-outs never happened;

2) Remove the 19 ids from the *old_issues* table and implement the fix.
Data is lost, would be as if the item was never checked out and then checked in 
again but, in theory, this would open room for the 19 ids in the issues when 
they check-in.

3) Update the 19 ids in the *issues* table to the next 19 ID's available, move 
the AI value 19 upwards and check if it's +1 than the current max(issue_id). 
This is, in theory, the best way as no data is lost, those
19 ID's in *issues* table would have their ID's available in the old_issues 
table, and the fix prevents the problem from happening in the future.
However this sounds the most risky way to go about it.

Would anyone give me advice or their opinion on this? Am I looking at this the 
right way or is there some other better way to work around it?

Thanks a bunch,

Pedro Amorim
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Salvaging data before using DBMS auto increment fix

[Marcel de Rooy]

Pedro,
Personally I would delete the 19 old ones. Your option 2. Easiest, no big data 
loss.. 
In contrast with your option 3 you could also renumber the 19 old issues in the 
deleted table. The autoincr will be reset when you add another record and you 
made room for the 19 new ones. It seems safer to me than touching the active 
issues. 
There is a bug about a script for this, but it got into In Discussion..

Marcel


-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Pedro Amorim
Verzonden: maandag 23 oktober 2017 14:13
Aan: Koha list 
Onderwerp: [Koha] Salvaging data before using DBMS auto increment fix

Hello all,

I want to implement
https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix on our instance, 
however from my understanding this will only prevent the problem from happening 
in the future, it will not fix the current corrupted data.

I happen to have 19 ids that exist on both issues and old_issues and would like 
to the clean-up before going further. However, I'm not sure how to
proceed:

1) Remove the 19 ids from the *issues* table and implement the fix.
Downside is the data of those 19 issues would be lost and it would be as if 
those check-outs never happened;

2) Remove the 19 ids from the *old_issues* table and implement the fix.
Data is lost, would be as if the item was never checked out and then checked in 
again but, in theory, this would open room for the 19 ids in the issues when 
they check-in.

3) Update the 19 ids in the *issues* table to the next 19 ID's available, move 
the AI value 19 upwards and check if it's +1 than the current max(issue_id). 
This is, in theory, the best way as no data is lost, those
19 ID's in *issues* table would have their ID's available in the old_issues 
table, and the fix prevents the problem from happening in the future.
However this sounds the most risky way to go about it.

Would anyone give me advice or their opinion on this? Am I looking at this the 
right way or is there some other better way to work around it?

Thanks a bunch,

Pedro Amorim
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Major, multiple problems with our Koha 17.05 system.

[Marcel de Rooy]

Very sorry to hear about your problems, Raymond.
Cant say very much about it, since we do not yet use 17.05.
But you should be searching on Bugzilla for the reports that got recently 
backported to 17.05.x.
Might just include some that you need. Upgrading to the latest 17.05 would then 
perhaps address some issues.
Just a side note: Very long delays in the past have been the result of date 
calculations with very far future dates like  in expiry dates etc. Setting 
them back temporarily has been helpful in the past. (No guarantees; may be 
other factors involved.)

Since your system is extensively customized, it could be helpful (for you) to 
know if your system without custom changes in a test environment would still 
experience the same problems..
And what about: Does your server have enough CPU and memory, etc ?

Just a few remarks. 

Marcel

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Raymund Delahunty
Verzonden: donderdag 12 oktober 2017 13:29
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Major, multiple problems with our Koha 17.05 system.

VERY long sorry, but our Koha system is virtually unusable and we need help!

We are experiencing dozens of outages daily (both OPAC and intranet, more often 
only OPAC) with our Koha 17.05.01.000 (Debian 3.2.89-2, perl 5.020002, mysql 
14.14, apache 2.4.10). Searches can take 15+ seconds. While university staff 
provide first tier support, we don't have server access, and the second tier 
and hosting is via an external company. Of course we are working with that 
company to have them identify the cause, but I have decided to ask the 
community of any user on 17.05 has the problems we have.

Our system is quite extensively customised, with major work done to the OPAC at 
https://libsearch.arts.ac.uk. We have some 
auto-renewal functionality we funded working, while we work on more 
improvements (we are NOT using the template toolkit, relying on workarounds to 
offer reasonably useful auto-renewal features).

Our problems started in the summer vacation soon after the upgrade, where Koha 
returns functionality became unstable. It was taking 8 seconds to return one 
item. Our support company advised that it was the AddReturn (and, in 
particular, MarkIssueReturned) which was the pinch point. Seems some code to 
resolve the auto_increment bug works slower in 17.05 and our support company 
was correcting that with a view (I understand) to adding it to Master.

Things improved a little, but with the start of term almost 2 weeks ago we are 
encountering so many problems...

"We were alerted to issues at 4.22pm. and found that the plack server was no 
longer responding. We restarted plack and then apache and the service restored. 
We are trying to get to the bottom of what caused this issue. It appears to be 
completely separate from the high CPU problem that we are also seeing."

I understand more resources have been allocated to mySQL and additional plack 
helpers have been allocated (whatever that means).

We are heavy users of SIP (80% of transactions are via self issue). But there 
are so many problems with the returns unit that they are almost unusable. Front 
line staff are fed up! The sorters and the kiosks configured for returns (as 
well as issue) fail repeatedly dozens of times daily (ERR_SIP_COM_RECV). 
Reconnection does happen- takes about 40seconds or so, leading to queues. And 
the items have NOT come off the account and flow into the exceptions bin. At 
the same time the intranet report 500 server errors. I am pretty sure most of 
our problems are related to returns code, but could well be wrong/ 
oversimplifying things.

Our support company advised:
"We have  added extra logging and can see that some checkin requests via the 
SIP2 protocol are causing the sipserver process to abort. The book is returned 
within Koha but as the process returns no information to the SIP2 client 
therefore the unit responds with an error. After waiting for the timeout period 
it then will reconnect to the server. We are adding further debug to the logs 
to work out why the sipserver process is aborting. It does seem to be a special 
subset of the checkin requests. I'll update you when we have more news."

And more problems relating to total outages (with proxy errors 502 relating to 
invalid responses from an upstream server):

"There appears to be a  number of issues you are experiencing. Friday you had 
high CPU usage which is different to today's issues which we think are down to 
the apache webserver not restarting correctly. I will double check first thing 
tomorrow that the overnight  apache restart has occurred properly. We are 
hoping the database connections change may address the high CPU issue. We will 
monitor closely for the errors we have seen in the apache error logs tomorrow."

We are a university with 20,000 students across 6 colleges, and right now 
inductions and training 

Re: [Koha] Checkout one item results in multiple items...

[Marcel de Rooy]

Adding your exact Koha version might be helpful too.


Marcel


Van: Koha  namens Tim Young 

Verzonden: dinsdag 10 oktober 2017 16:01:12
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Checkout one item results in multiple items...

We have started experiencing a recent issue where attempting to check
out one item results in multiple of those items (same barcode, checked
out multiple times) being checked out to the one patron.  This does not
happen to every item, nor does it happen to every patron.

I am not sure if this error has to do with the problem, but I am seeing
errors like:

[Tue Oct 10 15:49:58.258993 2017] [cgi:error] [pid 20067] [client
41.89.41.2:23363] AH01215: [Tue Oct 10 15:49:58 2017] additem.pl:
DBIx::Class::Storage::DBI::select_single(): Query returned more than one
row.  SQL that returns multiple rows is DEPRECATED for ->find and
->single at /usr/share/koha/lib/Koha/Objects.pm line 92, referer:
http://opac.scott.ac.ke:8080/cgi-bin/koha/cataloguing/additem.pl?op=edititem=15157=25724

showing up in the internet-error.log

Any clue how I should begin tracking this down?

 - Tim

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority

[Marcel de Rooy]

Depends on the time it gets pushed by RM and picked up by RMaint.

But should be possible for the 22th..


Van: Koha <koha-boun...@lists.katipo.co.nz> namens lists <li...@merit.unu.edu>
Verzonden: woensdag 6 september 2017 15:42:33
Aan: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority

Hi Marcel,

That looks *exactly* like our issue, thanks for pointing it out!

I see that the fix has been signed-off by you and Lee Jamison, I'm
guessing that means that it will included in the next version of koha.

The site tell us there are monthly releases, and since 17.05.03 was
released august 29, it seems we have to be a bit patient for the fix to
arrive on our system.

We're assuming this counts as a bugfix, and will be included in a
to-be-released 17.05.04, right?

MJ

On 6-9-2017 13:28, Marcel de Rooy wrote:
> Bug 18927 might be relevant to you.
>
>
> Marcel
>
> ________
> Van: Marcel de Rooy
> Verzonden: dinsdag 29 augustus 2017 16:59:26
> Aan: koha@lists.katipo.co.nz
> Onderwerp: Re: [Koha] KOHA Unimarc 606 field not connecting to subject 
> authority
>
>
> Probably a Zebra/UNIMARC configuration issue. (The harder ones..)
>
>
> Did you already try a complete rebuild btw ?
>
> Contact another UNIMARC user and compare zebra settings ? Or compare settings 
> with the situation before the last update?
>
>
> Check your zebra logs, zebra-error zebra-output. Maybe you must enable some 
> flags in koha-conf to get more verbose output. Follow the queries and look at 
> the fields used in these 'unreadable' @attr 1=xx form etc. Verify that these 
> fields are in the corresponding bib1.att under etc/koha/zebradb ..
>
>
> Marcel
>
> ___
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority

[Marcel de Rooy]

Bug 18927 might be relevant to you.


Marcel


Van: Marcel de Rooy
Verzonden: dinsdag 29 augustus 2017 16:59:26
Aan: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority


Probably a Zebra/UNIMARC configuration issue. (The harder ones..)


Did you already try a complete rebuild btw ?

Contact another UNIMARC user and compare zebra settings ? Or compare settings 
with the situation before the last update?


Check your zebra logs, zebra-error zebra-output. Maybe you must enable some 
flags in koha-conf to get more verbose output. Follow the queries and look at 
the fields used in these 'unreadable' @attr 1=xx form etc. Verify that these 
fields are in the corresponding bib1.att under etc/koha/zebradb ..


Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority

[Marcel de Rooy]

Probably a Zebra/UNIMARC configuration issue. (The harder ones..)


Did you already try a complete rebuild btw ?

Contact another UNIMARC user and compare zebra settings ? Or compare settings 
with the situation before the last update?


Check your zebra logs, zebra-error zebra-output. Maybe you must enable some 
flags in koha-conf to get more verbose output. Follow the queries and look at 
the fields used in these 'unreadable' @attr 1=xx form etc. Verify that these 
fields are in the corresponding bib1.att under etc/koha/zebradb ..


Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority

[Marcel de Rooy]

Hi MJ, Ad,

It seems that your cataloging plugin for 606 calls a Koha Plugin ? Is that 
right?
The first error mentioned refers to Koha/Plugins/Handler.pm.
If you do not have control over that plugin yourself, you'd better contact the 
author or supplier.
Perhaps a recent update interferes with the code of the plugin?

Marcel


-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens lists
Verzonden: maandag 28 augustus 2017 10:51
Aan: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] KOHA Unimarc 606 field not connecting to subject authority

Hi all,

Anyone with some feedback on the matter below?

Thanks you very much in advance,
MJ

On 23-8-2017 11:02, Ad Notten wrote:
> Dear Koha list users,
> 
> We have a problem in our system where, during the cataloging process 
> the subject field (606 in Unimarc) does not seem to connect to the 
> subject authority (plugin). We use the Unimarc framework and were 
> suspecting that the error was a result of a recent update which 
> mismatched the fields (MARC21-UNIMARC problem). However this all seems 
> to be well defined as the bibliographic framework tests all come back with an 
> OK.
> 
> Also the subject authority is available, because (for an existing
> record) it can be looked at both in the OPAC and in the cataloging 
> module. However it can not be used when editing or when making a new 
> record.
> 
> For the rest the whole cataloging process is fine and presents no errors.
> 
> We are running 16.11.08.000 on debian wheezy (8.8) using the packages 
> from the repository. The logs show the following:
> 
> Adding a biblio, results in some errors logged,but this seems to work fine:
> 
>> Wed Aug 23 10:18:56.192998 2017] [cgi:error] [pid 20428] [client 
>> 192.168.3.5:49497] AH01215: [Wed Aug 23 10:18:56 2017] Handler.pm: 
>> Use of uninitialized value $INC[-1] in string eq at 
>> /usr/share/koha/lib/Koha/Plugins/Handler.pm line 30,  line 
>> 751.,
>> referer: 
>> https://opac.company.com:888/cgi-bin/koha/cataloguing/additem.pl
>> [Wed Aug 23 10:18:56.423621 2017] [cgi:error] [pid 20428] [client 
>> 192.168.3.5:49497] AH01215: [Wed Aug 23 10:18:56 2017] addbooks.pl:
>> Use of uninitialized value $file in require at 
>> /usr/lib/x86_64-linux-gnu/perl5/5.20/Template/Plugins.pm line 206.,
>> referer: 
>> https://opac.company.com:888/cgi-bin/koha/cataloguing/additem.pl
>> [Wed Aug 23 10:19:00.572591 2017] [cgi:error] [pid 20428] [client 
>> 192.168.3.5:49497] AH01215: [Wed Aug 23 10:19:00 2017] Handler.pm: 
>> Use of uninitialized value $INC[-1] in string eq at 
>> /usr/share/koha/lib/Koha/Plugins/Handler.pm line 30,  line 
>> 751.,
>> referer: 
>> https://opac.company.com:888/cgi-bin/koha/cataloguing/addbooks.pl
>> [Wed Aug 23 10:19:00.853005 2017] [cgi:error] [pid 20428] [client 
>> 192.168.3.5:49497] AH01215: [Wed Aug 23 10:19:00 2017] addbiblio.pl:
>> Use of uninitialized value $file in require at 
>> /usr/lib/x86_64-linux-gnu/perl5/5.20/Template/Plugins.pm line 206.,
>> referer: 
>> https://opac.company.com:888/cgi-bin/koha/cataloguing/addbooks.pl
> 
> Then go to field 606 and search:
> 
>> [Wed Aug 23 10:21:30.720460 2017] [cgi:error] [pid 20534] [client 
>> 192.168.3.5:49505] AH01215: [Wed Aug 23 10:21:30 2017] ysearch.pl:
>> oAuth error: Unsupported Use attribute (114) authtype Bib-1, referer: 
>> https://opac.company.com:888/cgi-bin/koha/authorities/auth_finder.pl?
>> source=biblio=SUBJECT=tag_606_subfield_a_30266_787
>> 888_main=
>>
>> [Wed Aug 23 10:21:32.292900 2017] [cgi:error] [pid 20536] [client 
>> 192.168.3.5:49506] AH01215: [Wed Aug 23 10:21:32 2017] auth_finder.pl:
>> oAuth error: Unsupported Use attribute (114) authtype Bib-1, referer: 
>> https://opac.company.com:888/cgi-bin/koha/authorities/auth_finder.pl?
>> source=biblio=SUBJECT=tag_606_subfield_a_30266_787
>> 888_main=
>>
>> [Wed Aug 23 10:21:32.293038 2017] [cgi:error] [pid 20536] [client 
>> 192.168.3.5:49506] AH01215: [Wed Aug 23 10:21:32 2017] auth_finder.pl:
>> Use of uninitialized value $total in subtraction (-) at 
>> /usr/share/koha/intranet/cgi-bin/authorities/auth_finder.pl line 80, 
>>  line 751., referer:
>> https://opac.company.com:888/cgi-bin/koha/authorities/auth_finder.pl?
>> source=biblio=SUBJECT=tag_606_subfield_a_30266_787
>> 888_main=
>>
>> [Wed Aug 23 10:21:32.293144 2017] [cgi:error] [pid 20536] [client 
>> 192.168.3.5:49506] AH01215: [Wed Aug 23 10:21:32 2017] auth_finder.pl:
>> Use of uninitialized value $total in numeric gt (>) at 
>> /usr/share/koha/intranet/cgi-bin/authorities/auth_finder.pl line 105, 
>>  line 751., referer:
>> https://opac.company.com:888/cgi-bin/koha/authorities/auth_finder.pl?
>> source=biblio=SUBJECT=tag_606_subfield_a_30266_787
>> 888_main=
>>
>> [Wed Aug 23 10:21:32.293244 2017] [cgi:error] [pid 20536] [client 
>> 192.168.3.5:49506] AH01215: [Wed Aug 23 10:21:32 2017] auth_finder.pl:
>> Use of uninitialized value $total in numeric lt (<) at 
>> /usr/share/koha/intranet/cgi-bin/authorities/auth_finder.pl line 

[Koha] FW: kohadevbox problems

[Marcel de Rooy]

Bug 19163 is trivial but CRITICAL !



Van: Marcel de Rooy
Verzonden: dinsdag 22 augustus 2017 16:14
Aan: Hugo Agud; Koha ML
Onderwerp: Re: [Koha] kohadevbox problems


Hugo,

You found an error. Probably depending on a new pushed fix (bug 19049)

Fix is coming. If you could test, that would be great..

But finding and reporting is already a good thing..


Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] kohadevbox problems

[Marcel de Rooy]

The stage marc import script does not run under Plack. So the errors go to 
intranet-error.log

Please check for some warnings there.


Marcel



Van: Koha  namens Hugo Agud 
Verzonden: dinsdag 22 augustus 2017 10:12
Aan: Koha list
Onderwerp: [Koha] kohadevbox problems

Good morning

Since last week I am not able to stage marc records in kohadevbox
machines.. no logs, no errors ... just

I am to load records via z39 or cataloguin, although the indexer it soesn't
start until I restat koha-common..


   - Processing bibliographic records
   - 0 records in file
   - 0 records not staged because of MARC error
   - 0 records staged
   - Did not check for matches with existing records in catalog
   - 0 item records found and staged


The files upload fine to the server

-rw-r--r-- 1 kohadev-koha kohadev-koha 586763 Aug 22 08:05
20277b0030d1556b1573c125b5bc2570_demo.mrc

-rw-r--r-- 1 kohadev-koha kohadev-koha 586763 Aug 22 08:08
ce8d642056e458562d72cd7fa6dfe84d_demo.mrc

-rw-r--r-- 1 kohadev-koha kohadev-koha   7302 Aug 22 08:08
cc66ac5be3b994f8d277ca70947da74c_84420.mrc

-rw-r--r-- 1 kohadev-koha kohadev-koha   7302 Aug 22 08:08
01f8e6cfb381ec3944c14d068c99be97_84420.mrc


any idea?

--

*Hugo Agud - Orex Digital *

*www.orex.es *


[image: www.orex.es/koha] 


Koha: Sistema Integrado de Gestión de Bibliotecas - Orex 
...
www.orex.es
Primer sistema integral de gestión de bibliotecas opensource del mundo, Orex 
ofrece servicios de implementación, migración, mantenimiento y soporte de Koha.



   [image: www.orex.es/vufind] 


Vufind: Punto único de Acceso y Catálogo Colectivo - Orex 
...
www.orex.es
Vufind Crea un catálogo colectivo entre diferentes bibliotecas o un punto de 
acceso único a todos los fondos de una o más bibliotecas



Vufind: Punto único de Acceso y Catálogo Colectivo - Orex 
...
www.orex.es
Vufind Crea un catálogo colectivo entre diferentes bibliotecas o un punto de 
acceso único a todos los fondos de una o más bibliotecas





Omeka: Repositorio y Exposición Cultural Online - Orex 
Digital
www.orex.es
Crea repositorios y repositorios multimedias y exposiciones virtuales 
interactivas y cooperativas con otras instituciones y otros usuarios





Director

Calle Sant Joaquin,117, 2º-3ª · 08922 Santa Coloma de Gramanet - Tel: 933
856 138   ha...@orex.es · http://www.orex.es/

Orex: Expertos en Software Libre: Koha, vufind y Omeka
www.orex.es
Implementación, migración, soporte y mantenimiento de aplicaciones Opensource 
para centros de documentación: Koha, Vufind y Omeka.






No imprima este mensaje a no ser que sea necesario. Una tonelada de papel
implica la tala de 15 árboles y el consumo de 250.000 litros de agua.



Aviso de confidencialidad
Este mensaje contiene información que puede ser CONFIDENCIAL y/o de USO
RESTRINGIDO. Si usted no es el receptor deseado del mensaje (ni
está autorizado a recibirlo por el remitente), no está autorizado a copiar,
reenviar o divulgar el mensaje o su contenido. Si ha recibido este mensaje
por error, por favor, notifíquenoslo inmediatamente y bórrelo de su sistema.
___
Koha mailing list  http://koha-community.org

Official Website of Koha Library Software
koha-community.org
Koha Library Software The world's first free and open source library system 
Koha is a fully featured, scalable library management system. Development is 
sponsored by ...



Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Koha --Discussion list for the Koha Library system - 
Katipo
lists.katipo.co.nz
To see the collection of prior postings to the list, visit the Koha Archives. 
Using the Koha Mailing List: To post a message to all the list ...



___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Confusion over "item type"

[Marcel de Rooy]

Chris,


You should look for the pref item-level_itypes and its documentation.


Marcel



Van: Koha  namens Chris Brown 

Verzonden: woensdag 9 augustus 2017 13:12
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Confusion over "item type"

Hello,

MARC records 942$c and 952$y both appear to specify an "item type". They
appear to be mapped to koha fields biblio.itemtype and items.itype
respectively. Please could someone explain to me the difference between
them? In particular when I define a circulation rule for a specific item
type, which one does it use?

I am using Koha 17.05

Thanks!

Chris Brown (still a newbie, but getting there ...)
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] MARC frameworks in Koha

[Marcel de Rooy]

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 mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Serials: Irregularities

[Marcel de Rooy]

Hi all,

This is a paste from bug 17656:
==

The current irregularity feature works with saving internal fictive issue 
numbers in a text field irregularity. If you edited/shifted some dates in 
serial collection, you might be surprised what happens.

You cannot view the saved irregularities in serial collection (I only see e.g. 
2 issues on the Planning tab); they are only visible when editing the 
subscription and looking at the prediction pattern again.



Bug 18365 and 
friends made it easier to handle discrepancies in the schedule. An occasional 
irregularity could be resolved that way.



Would it be useful to define recurring irregularities in terms of the serial 
frequency chosen? If it is month, we could allow the user to select one or more 
months to skip? Same for weeks or days. (Year seems less interesting.)

Doing this would replace selection of irregulars in the prediction pattern.



If so, how should we handle 'special' frequencies like 1 per 3 months or 3 per 
month btw? Skip all in e.g. July or refine with skip second in July etc.?



It seems to me that we should make the irregularity info more visible to the 
user too on Serial collection form.

==

If you are working on serials and have some thoughts about this, please share 
them on the Bugzilla report.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17656

Thanks,
Marcel


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] Koha 17.05.00 released!

[Marcel de Rooy]

Great! Thanks Kyle.



Van: koha-devel-boun...@lists.koha-community.org 
 namens Kyle Hall 

Verzonden: woensdag 31 mei 2017 04:13
Aan: Koha Devel; Koha
Onderwerp: [Koha-devel] Koha 17.05.00 released!

Hello all!

It is my honor to announce the release of Koha 17.05.00!

Thanks you to everyone who contributed time and effort making this the best 
version of Koha yet!

The release notes can be found on the Koha Community website: 
https://koha-community.org/koha-17-05-released/

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )

Meadville Public Library | what's happening @ your 
library
www.meadvillelibrary.org
Location, hours and circulation policy.



Crawford County Federated Library System ( http://www.ccfls.org )

ccfls.org - the libraries of Crawford County, PA
www.ccfls.org
The Crawford County Federated Library System (CCFLS) is pleased to announces 
the installation of Koha Zoom Intergrated Library System (ILS) catalog and 
circulation ...



___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] [Second call] Need feedback on lists (virtual shelves) permissions

[Marcel de Rooy]

Appreciate any feedback. Or we should just guess what is best for you :)


Marcel



Van: Marcel de Rooy
Verzonden: dinsdag 11 april 2017 16:57
Aan: Koha ML
Onderwerp: Need feedback on lists (virtual shelves) permissions


Hi all,


On Bugzilla report 18228 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18228 I have proposed 
to merge the currently separated Add and Delete permission for entries on a 
list into a new Change permission.

This BZ attachment 
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60943 shows you the 
new options: Change is allowed for Nobody (readonly), Owner only, or Anyone 
seeing the list.

Owen suggested to hide the "Anyone seeing the list" option for private lists.


As a plea in favor of the new design, I would add that (apart from simplifying 
something that confused people) we could see the list as a document containing 
lines. If we allow someone to change the document, he is able to add and delete 
lines. In Koha we are actually not interested in who added a line (entry to the 
list). The information is saved but only used in context of the old permission 
scheme. We follow a similar principle with e.g. biblios or patrons: if we have 
edit/modify/change permission, we can add and delete a biblio, a patron, etc.


So, my main question is now: Would you consider this as a welcome 
simplification or as feature loss? Are you heavily leaning on the separation of 
add and delete permissions?

If you can add a response on the Bugzilla report, please do. Otherwise reply to 
the list.


Thanks,

Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Need feedback on lists (virtual shelves) permissions

[Marcel de Rooy]

Hi all,


On Bugzilla report 18228 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18228 I have proposed 
to merge the currently separated Add and Delete permission for entries on a 
list into a new Change permission.

This BZ attachment 
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=60943 shows you the 
new options: Change is allowed for Nobody (readonly), Owner only, or Anyone 
seeing the list.

Owen suggested to hide the "Anyone seeing the list" option for private lists.


As a plea in favor of the new design, I would add that (apart from simplifying 
something that confused people) we could see the list as a document containing 
lines. If we allow someone to change the document, he is able to add and delete 
lines. In Koha we are actually not interested in who added a line (entry to the 
list). The information is saved but only used in context of the old permission 
scheme. We follow a similar principle with e.g. biblios or patrons: if we have 
edit/modify/change permission, we can add and delete a biblio, a patron, etc.


So, my main question is now: Would you consider this as a welcome 
simplification or as feature loss? Are you heavily leaning on the separation of 
add and delete permissions?

If you can add a response on the Bugzilla report, please do. Otherwise reply to 
the list.


Thanks,

Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Fwd: Error in Koha

[Marcel de Rooy]

AFAIK The non-XSLT view has been deprecated. 

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens mj
Verzonden: woensdag 5 april 2017 18:56
Aan: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] Fwd: Error in Koha

Hi all,

For the archives: our problem was solved with the help of biblibre: we disabled 
XSLT for the opac.

Hopefully this solution will help someone in a similar situation.

MJ

On 04/03/2017 02:24 PM, Jonathan Druart wrote:
> Hello,
>
> You should contact directly your support provider if you have one, or 
> used to have one.
> I was talking about MARC field, not DB Field.
> Re-read my answer with thinking MARC field instead of DB field.
>
> Regards,
> Jonathan
>
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] "Item-level_itypes set but no itemtype set" leads to 'Can't locate object method "ymd"'

[Marcel de Rooy]

Bug 17502 still needs your attention btw.


Van: Koha  namens King, Fred 

Verzonden: donderdag 29 december 2016 21:39
Aan: 'Jonathan Druart'; koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] "Item-level_itypes set but no itemtype set" leads to 
'Can't locate object method "ymd"'

Thank you! It worked like a charm. Given that we're a medical library and one 
of the titles making Koha crash was the New England Journal of Medicine, it's 
kinda nice to have the problem fixed.

Fred King
Medical Librarian, MedStar Washington Hospital Center
fred.k...@medstar.net
202-877-6670
ORCID -0001-5266-0279

I have one of those metabolisms where I can eat whatever I want and my body 
converts it to energy and stores the excess as fat.
--Randall Munroe, xkcd


-Original Message-
From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Jonathan Druart
Sent: Thursday, December 29, 2016 4:05 AM
To: koha@lists.katipo.co.nz
Subject: Re: [Koha] "Item-level_itypes set but no itemtype set" leads to 'Can't 
locate object method "ymd"'

Hello Fred,

If bug 17502 fixes your problem that mean that you have the items.onloan field 
set to '-00-00'. That could happen with old database. The easiest way to 
fix it is to fix the value in the database directly.
You can fix it (without applying the patch) by setting this value to NULL.
Otherwise apply the patch and sign it off :)

Same for the other error (item-level_itypes). It is not related but you can fix 
it by setting a relevant value for the items.itype row.

Regards,
Jonathan


On Wed, 28 Dec 2016 at 19:36 King, Fred  wrote:

> Greetings to all,
>
> System: Koha 16.11.00, Ubuntu 14.04.
>
> When I rebuild zebra, I get a series of error messages
> "item-level_itypes set but no itemtype set for item (itemnumber) at
> /usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698." I've looked
> up the corresponding biblio number and barcode for the items in an
> inventory report, but when I try to search for them I get the error
> message 'Can't locate object method "ymd" via package "dateonly"
> (perhaps you forgot to load "dateonly"?) at
> /usr/share/koha/lib/Koha/DateUtils.pm line 225.' I get the same
> message whether I search for item number, biblio number, barcode, or
> title. Some of the items don't have barcodes-I don't know whether that's part 
> of the problem.
>
> It looks as if part of the 'Can't locate object method "ymd"' problem
> is being fixed with Bug 17502, but I can't tell if it's just a date
> problem that I can fix easily since I can't call up the record to look
> at it. Same with item-level itemtype.
>
> Does this sound familiar to anyone? Does anyone know of a way to call
> up items that keep crashing Koha?
>
> Thanks,
>
> Fred King
> Medical Librarian, MedStar Washington Hospital Center
> fred.k...@medstar.net
> 202-877-6670
> ORCID -0001-5266-0279
>
> I have one of those metabolisms where I can eat whatever I want and my
> body converts it to energy and stores the excess as fat.
> --Randall Munroe, xkcd
>
> --
> MedStar Health is a not-for-profit, integrated healthcare delivery
> system, the largest in Maryland and the Washington, D.C., region.
> Nationally recognized for clinical quality in heart, orthopaedics, cancer and 
> GI.
>
> IMPORTANT: This e-mail (including any attachments) may contain
> information that is private, confidential, or protected by
> attorney-client or other privilege. If you received this e-mail in
> error, please delete it from your system without copying it and notify
> sender by reply e-mail, so that our records can be corrected... Thank you.
>
> Help conserve valuable resources - only print this email if necessary.
>
>
> ___
> Koha mailing list
> https://urldefense.proofpoint.com/v2/url?u=http-3A__koha-2Dcommunity.o
> rg=DgIGaQ=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M=vKh6XwOmjy
> C51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI=1pNbP9tdwRUjkMqcQgZI4ChKlcb6HMWTEP
> 3123-GuwA=-frC1YRdTzSYrBFay6MUtY5dIwq-fPy3gppma9a9w1Q=
> Koha@lists.katipo.co.nz
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.katipo.co.n
> z_mailman_listinfo_koha=DgIGaQ=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVx
> j8-bJ04M=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI=1pNbP9tdwRUjk
> MqcQgZI4ChKlcb6HMWTEP3123-GuwA=7NwEP5Zq8EKhBFmtrVvrWo18CzKu09Q368eat
> ipln-g=
>
___
Koha mailing list  
https://urldefense.proofpoint.com/v2/url?u=http-3A__koha-2Dcommunity.org=DgIGaQ=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI=1pNbP9tdwRUjkMqcQgZI4ChKlcb6HMWTEP3123-GuwA=-frC1YRdTzSYrBFay6MUtY5dIwq-fPy3gppma9a9w1Q=
Koha@lists.katipo.co.nz

Re: [Koha] MySQL database server, dedicated vs virtual

[Marcel de Rooy]

Please note:

Staying at Koha 3.8 is not recommended. The current release (16.11 == 3.26) is 
already 9(!) release cycles behind..

And I would not advise others to do so.


Marcel



Van: Koha  namens Paul A 

Verzonden: vrijdag 2 december 2016 21:53
Aan: koha
Onderwerp: Re: [Koha] MySQL database server, dedicated vs virtual

Roger,

We also looked into the "search performance" last year. We are not a
lending library, so cataloguing and OPAC are our primary concerns. Please
see  for the detailed tech analysis
and conclusions.

You mention below that "Koha does not benefit a lot from multiple CPU cores
since each CGI request is typically processed by one CPU except for the
Zebra searches and database queries which run as separate processes."

I talked to Intel about CPU core cross-threading as it was a very obvious,
high-load, show-stopper with Zebra. The Zebra author never replied to my
queries. Intel were not optimistic, as kernel (and software) were not their
bailliwick. I do not know if Plack or Elastic have worked around this.

These are hardware (perhaps software usage of core capability), not Koha,
restrictions. Tweaking memcached can have appreciable benefits. But the
bottom line remains that if a single CPU core hits 101-104%, search
functions descend into the "swimming upstream in treacle" world.

We made the very conscious (but disappointing) decision to stay with Koha
3.8.24 based on our test results. I do spend quite some time testing later
versions at "sandbox" level, but have not been able to reproduce "older"
search speed.

YMMV -- Paul
Production: Koha 3.8.24 on 14.04.2 LTS (GNU/Linux 3.13.0-43-generic
x86_64), 8-core I7 processors, 64 Gigs RAM, all SSD drives.




At 06:47 PM 12/2/2016 +0100, Roger Grossmann wrote:

>Hi Tobias,
>
>a few month ago we did comparisons measuring the Koha-OPAC-Search
>performance with plack and memcached enabled using version 3.22.
>Our tests were not scientifically organised. We wanted to gather
>experience running Koha in different environments. We used the same MySQL
>database and Koha version in all environments. We did two types of OPAC
>searches on a limited collection of about 50.000 titles: an 'a*'-search of
>the complete word index and some special searches with fixed title search
>terms.
>We tested the following environments:
>
>1) Full Koha installation on a cloud provider hosted VM (the performance
>of VMs of the specific hoster were high ranked in published comparisons):
>Debian 8 on a cloud hosted system with virtual 2CPUs, 8 GB RAM, 256 SSD
>2) Full Koha installation on a physical server: Debian 8 on a well
>equipped physical machine with 64 GB RAM, 4 processors, 250 GB SSD
>3) Full Koha installation on a kvm-VM on a physical server: Debian 8 on a
>well equipped machine with 64 GB RAM, 4 core CPUs, kvm VM with Debian 8
>4) Koha running on a physical machine like 2) and 3) with a separate
>physical DB Server. Koha and DB server were connected through a 1 GB network.
>
>Our findings were the following:
>No wonder, environment 2 was the fastest. Running Koha on a physical
>server with the database on the same machine brings optimal performance.
>As a surprise, environment 3 had a performance closed to environment 2
>with a difference of max. 5% performance loss. The kvm virtualiser seems
>to add very little overhead. Advantages of environment 3 are beside the
>high performance that it is possible to copy and save the VM doing updates
>and so on. We did not test running multiple kvm-VMs on the same host.
>Rather than running instances in separate VMs, Koha's concept of managing
>instances makes the use of one host very efficient. Running multiple
>instances in one machine requires less maintenance than running multiple
>VMs each with one Koha instance.
>Environment 1 was about 60-80% slower than environment 2. We got varying
>results probably depending on the load of the provider based environment.
>Server requests in environment 4 took double the time of environment 1. It
>seemed that the network latency and transmission of data between DB Server
>and Koha is a bottleneck here.
>
>We can recommend option 3. It brings an optimum of performance with the
>flexibility of a virtualised environment. For a single Koha instance you
>probably do not need more than 2 CPUs cores. Typically you can improve the
>database performance with an optimised database configuration
>(specifically the page buffer if you have enough RAM). So using >=16 GB
>RAM should be well equipped from my perspective.
>Key parameters to speed up Koha were in our tests the hard disk speed (use
>SSDs) and CPU speed. Koha does not benefit a lot from multiple CPU cores
>since each CGI request is typically processed by one CPU except for the
>Zebra searches and database queries which run as separate processes.
>Additional CPU cores can be useful if the load 

Re: [Koha] Cannot upload .mrc file for staging Marc records

[Marcel de Rooy]

FYI We plan to start translation of Dutch NL for 3.22 in the next few weeks.


Van: Koha  namens Tajoli Zeno 

Verzonden: donderdag 15 september 2016 15:50:57
Aan: bram vermeir; koha ml
Onderwerp: Re: [Koha] Cannot upload .mrc file for staging Marc records

Hi,

Il 15/09/2016 14:25, bram vermeir ha scritto:
> That must be it.
> I disabled the Dutch language and it fixed the problem.
>  I have some issues and errors when trying to retranslate.
> So I can't reactivate Dutch for now.

in fact today the dutch translation is impossible to use.
For 16.05 only 8% of strings are done.

If you want to use it, go here:
http://translate.koha-community.org/nl_NL/16.05/

Is it a good idea to start to transalte and fix opac.
You need an account on the server to do transaltion.

Ask for it in mailing list koha-transl...@lists.koha-community.org
[http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate]

Bye
Zeno Tajoli

--
Zeno Tajoli
/SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche
Email: z.taj...@cineca.it Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Cannot upload .mrc file for staging Marc records

[Marcel de Rooy]

Dutch is not a bad choice :)

Van: bram vermeir [mailto:vermeir_b...@hotmail.com]
Verzonden: donderdag 15 september 2016 14:25
Aan: Marcel de Rooy <m.de.r...@rijksmuseum.nl>; koha ml 
<koha@lists.katipo.co.nz>
Onderwerp: Re: [Koha] Cannot upload .mrc file for staging Marc records


That must be it.

I disabled the Dutch language and it fixed the problem.

I have some issues and errors when trying to retranslate.

So I can't reactivate Dutch for now.

Thanks




Van: Koha 
<koha-boun...@lists.katipo.co.nz<mailto:koha-boun...@lists.katipo.co.nz>> 
namens Marcel de Rooy 
<m.de.r...@rijksmuseum.nl<mailto:m.de.r...@rijksmuseum.nl>>
Verzonden: donderdag 15 september 2016 7:10:19
Aan: koha ml
Onderwerp: Re: [Koha] Cannot upload .mrc file for staging Marc records

> Hmm it was deleted, but it looks like the code is still trying to use it. Or 
> there wouldn't be that error in the logs.



Could this be originating from an older template file (non-English one) or so ? 
Forgot to retranslate the templates ?

This script should not be in the code any longer.


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] search quits working

[Marcel de Rooy]

Adding this comment to bug 16885. Thanks.



Van: Koha <koha-boun...@lists.katipo.co.nz> namens Philippe Blouin 
<philippe.blo...@inlibro.com>
Verzonden: dinsdag 2 augustus 2016 16:47
Aan: Scott Owen; Nombre
CC: koha
Onderwerp: Re: [Koha] search quits working

(sorry, jumping into the thread)

We've had this problem on 10% of our installations.  I solved it by
going nuclear with logrotate since that was really hurting the users to
not have zebra working (it would appear like working on our monitor, but
was actually just dying and restarting).

Here is the postrotate I've end up with, after many iterations of Next
Level Apocalypse You :)

 postrotate
 service apache2 reload
 find /etc/init.d/ -name "*zebra-daemon" -exec bash -c 'service
"$(basename "$0")" stop' {} \;
 sleep 3
 find /etc/init.d/ -name "*zebra-daemon" -exec bash -c 'service
"$(basename "$0")" stop' {} \;
 sleep 3
 pkill -9 zebra
 sleep 2
 pkill -9 zebra
 sleep 2
 find /etc/init.d/ -name "*zebra-daemon" -exec bash -c 'service
"$(basename "$0")" start' {} \;
 endscript

As you see, no subtlety, but I've had no problem for a year now...

Philippe Blouin,
Responsable du développement informatique

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

inLibro | pour esprit libre | www.inLibro.com<http://www.inLibro.com> 
<http://www.inLibro.com>
On 08/02/2016 10:08 AM, Scott Owen wrote:
> Hi,
>
> I'm finally getting back to my Koha issues.
>
>
> "I'm going to test adding a line
>
> /bin/sleep 5
>
> as first command in postrotate in logrotate.d/koha-common. I'll see
> tomorrow."
>
> Nombre, did this work for you ??
>
> or is the issue maybe fixed in the latest release ??
>
>
> -S
>
>
>
>
>
>
> On Fri, Jul 22, 2016 at 7:52 AM, Nombre <d0...@yahoo.es> wrote:
>
>> El 21/07/16 a las 14:55, Marcel de Rooy escribió:
>>> Bug 16885 ?
>> I'm going to test adding a line
>>
>> /bin/sleep 5
>>
>> as first command in postrotate in logrotate.d/koha-common. I'll see
>> tomorrow.
>>
>> Regards
>>
>>> -Oorspronkelijk bericht-
>>> Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Tomas Cohen
>> Arazi
>>> Verzonden: donderdag 21 juli 2016 14:27
>>> Aan: Scott Owen <so...@edzone.net>; Paul A <
>> pau...@navalmarinearchive.com>
>>> CC: koha <koha@lists.katipo.co.nz>
>>> Onderwerp: Re: [Koha] search quits working
>>>
>>> I blame logrotate.
>>>
>>> El jue., 21 jul. 2016 a las 9:12, Scott Owen (<so...@edzone.net>)
>> escribió:
>>>> Sorry
>>>> Debian, latest version of Koha.
>>>>
>>>> problem *seems* to have only started when I updated to the latest Koha
>>>> version.
>>>>
>>>>
>>>> 3.22.06.000
>>>> Linux hskoha 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2
>>>> (2016-04-08)
>>>> i686
>>>>
>>>>
>>>> The issue seems to be with the zebra server somehow coming to a halt,
>>>> and bailing.seemingly @ approx. 7:35 daily.
>>>>
>>>> a quick command of " koha-start-zebra  " makes things
>>>> all-good.and I can search again.
>>>>
>>>> However, within a couple of daysthe zebra server appears to die
>> again.
>>>> I have two servers, both at exactly the same rev. and they are both
>>>> exhibiting this behavior. Starting to look at some of the cron.daily
>>>> commands.they seem the most likely suspect (in my eyes)
>>>>
>>>>
>>>>
>>>> cron.daily -->>
>>>>
>>>> #!/bin/sh
>>>> # /etc/cron.daily/koha-common -- Daily housekeeping tasks for all Kohas.
>>>> # Copyright 2010  Catalyst IT, Ltd
>>>> #
>>>> # This program is free software: you can redistribute it and/or modify
>>>> # it under the terms of the GNU General Public License as published by
>>>> # the Free Software Foundation, either version 3 of the License, or #
>>>> (at your option) any later version.
>>>> #
>>>> # This program is distributed in the hope that it will be useful, #
>>>> but WITHOUT ANY WARRANTY; without even the implied warranty of #
>>>> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the # GNU
>>>> Ge

Re: [Koha] [Koha-devel] General IRC Meeting 3 August 2016 / Kohacon 2017 bidder information

[Marcel de Rooy]

> as Kohacon was in Europe this year and can't be in the same continent within 
> 3 years.


Little bit a side note:

As I understand, this is some kind of unwritten rule in the community.

Maybe we should write it down somewhere and relax it a little bit?


KohaCon should preferably not be held on the same continent twice in a row 
(unless an alternative is not available).

Or something similar ??

Marcel



___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] search quits working

[Marcel de Rooy]

Bug 16885 ?

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Tomas Cohen Arazi
Verzonden: donderdag 21 juli 2016 14:27
Aan: Scott Owen ; Paul A 
CC: koha 
Onderwerp: Re: [Koha] search quits working

I blame logrotate.

El jue., 21 jul. 2016 a las 9:12, Scott Owen () escribió:

> Sorry
> Debian, latest version of Koha.
>
> problem *seems* to have only started when I updated to the latest Koha 
> version.
>
>
> 3.22.06.000
> Linux hskoha 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 
> (2016-04-08)
> i686
>
>
> The issue seems to be with the zebra server somehow coming to a halt, 
> and bailing.seemingly @ approx. 7:35 daily.
>
> a quick command of " koha-start-zebra  " makes things 
> all-good.and I can search again.
>
> However, within a couple of daysthe zebra server appears to die again.
>
> I have two servers, both at exactly the same rev. and they are both 
> exhibiting this behavior. Starting to look at some of the cron.daily 
> commands.they seem the most likely suspect (in my eyes)
>
>
>
> cron.daily -->>
>
> #!/bin/sh
> # /etc/cron.daily/koha-common -- Daily housekeeping tasks for all Kohas.
> # Copyright 2010  Catalyst IT, Ltd
> #
> # This program is free software: you can redistribute it and/or modify 
> # it under the terms of the GNU General Public License as published by 
> # the Free Software Foundation, either version 3 of the License, or # 
> (at your option) any later version.
> #
> # This program is distributed in the hope that it will be useful, # 
> but WITHOUT ANY WARRANTY; without even the implied warranty of # 
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the # GNU 
> General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License # 
> along with this program.  If not, see .
>
> koha-foreach --enabled --email /usr/share/koha/bin/cronjobs/ 
> overdue_notices.pl -t koha-foreach --enabled 
> /usr/share/koha/bin/cronjobs/fines.pl
> koha-foreach --enabled --email /usr/share/koha/bin/cronjobs/ 
> advance_notices.pl -c koha-foreach --enabled 
> /usr/share/koha/bin/cronjobs/membership_expiry.pl
> -c
> koha-foreach --enabled /usr/share/koha/bin/cronjobs/holds/
> cancel_expired_holds.pl >/dev/null 2>&1 koha-foreach --enabled 
> /usr/share/koha/bin/cronjobs/services_throttle.pl > /dev/null 2>&1 
> koha-foreach --enabled 
> /usr/share/koha/bin/cronjobs/cleanup_database.pl --sessions 
> --zebraqueue 10 --list-invites koha-foreach --enabled --noemail 
> /usr/share/koha/bin/cronjobs/ cleanup_database.pl --mail koha-foreach 
> --enabled /usr/share/koha/bin/cronjobs/holds/
> auto_unsuspend_holds.pl > /dev/null 2>&1 koha-foreach --enabled 
> /usr/share/koha/bin/cronjobs/automatic_renewals.pl
> koha-run-backups --days 2 --output /var/spool/koha
>
>
>
>
> On Wed, Jul 20, 2016 at 6:41 PM, Paul A 
> 
> wrote:
>
> > At 10:20 AM 7/20/2016 -0400, Scott Owen wrote:
> >
> >> Hi all,
> >> I'm having some issues with Koha searching from both the OPAC and 
> >> the staff Intranet.
> >> I have tried several solutions for reindexing etc...
> >> including
> >> ---Koha-rebuild-zebra -f -v -b mylibrary and ---export 
> >> PERL5LIB=/usr/share/koha/lib ---export 
> >> KOHA_CONF=/usr/share/koha/koha-conf.xml
> >> ---perl /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r 
> >> -v -run-as-root
> >>
> >
> > You don't say which version of Koha, nor what o/s you are using. 
> > Assuming Debian/Ubuntu, what does printenv give you? You should see 
> > something like (amongst other lines):
> >
> > me@my_server:/$ printenv
> > PERL5LIB=/usr/share/koha/lib
> >
> >
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr
> /local/lib/perl
> > KOHA_CONF=/usr/share/koha/koha-conf.xml
> > KOHA_PATH=/usr/share/koha
> >
> > I'm also a little surprised by your "-run-as-root" -- in slightly 
> > older versions of Koha, this was a "no-no", but may well have 
> > changed
> (mpm-itk?)
> >
> > There is also something I noticed in further emails:
> >
> > > your zebra error logs.
> > [snip]
> > > 20160713 07:36:11 dlpms-koha-zebra: client (pid 526) killed by 
> > > signal
> > 15, stopping
> > > 20160713 07:40:07 dlpms-koha-zebra: client (pid 10116) killed by 
> > > signal
> > 15, stopping
> >
> > What were the 9590 processes in the <4 minutes? That log entry would 
> > certainly get my attention.
> >
> > Best -- P.
> >
> >
> > none of these commands produce any errors, however, they also do not 
> > fix
> >> the issue.
> >>
> >>
> >> A reboot of the VM will cause the "search" to work again for a day 
> >> or two??
> >> (I know."it shouldn't make a difference" ...but it 
> >> does...!?!?!?)
> >>
> >>
> >> I'm unsure of exactly where to start troubleshooting ???
> >>
> >> Any advise on where to begin ??
> >>
> >> Thanks,
> >>
> >> -S
> 

Re: [Koha] My next adventure

[Marcel de Rooy]

Success, Nicole and thx for your work in the Koha community. 

Marcel

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Nicole Engard
Verzonden: donderdag 14 juli 2016 1:21
Aan: Christopher Davis 
CC: Koha 
Onderwerp: Re: [Koha] My next adventure

Christopher,

It's a fancy way to say that I'll be helping get the documentation teams 
organized.  It's basically a project management position and it's right up my 
alley :)

Nicole

On Wed, Jul 13, 2016 at 4:11 PM, Christopher Davis 
wrote:

> Nicole,
>
> Please forgive my ignorance, but what does a "Content Strategist at 
> Red Hat" do?
>
> Thank you,
>
> Christopher Davis, MLS
> Systems & E-Services Librarian
> Uintah County Library
> cgda...@uintah.utah.gov
> (435) 789-0091 ext.261
> uintahlibrary.org
> basinlibraries.org
> facebook.com/uintahcountylibrary
> instagram.com/uintahcountylibrary
>
>
> On Wed, Jul 13, 2016 at 2:58 PM, Christopher Davis 
>  wrote:
> > Nicole,
> >
> > Will the Koha universe ever be the same without you? Thank you for 
> > all of your work on Koha as a developer and as an employee of BWS. 
> > You won't ever know the example you have set for us as an advocate 
> > of Koha and for open source software. I wish you all the best in the 
> > next stage of your career. You will be missed :')
> >
> > Take care,
> >
> > Christopher Davis, MLS
> > Systems & E-Services Librarian
> > Uintah County Library
> > cgda...@uintah.utah.gov
> > (435) 789-0091 ext.261
> > uintahlibrary.org
> > basinlibraries.org
> > facebook.com/uintahcountylibrary
> > instagram.com/uintahcountylibrary
> >
> >
> > On Wed, Jul 13, 2016 at 2:03 PM, Joann Ransom 
> > 
> wrote:
> >> Wow - congratulations Nicole - and thank you for all you have done 
> >> for Koha. Red Hat are lucky to have you
> >>
> >> Cheers jo
> >> On 14/07/2016 7:06 AM, "Nicole Engard"  wrote:
> >>
> >>> Hello friends!
> >>>
> >>> I wanted to reach out and let you all know that my last day at 
> >>> ByWater
> will
> >>> be July 29th.  I do plan to remain a member of the Koha community 
> >>> and
> to
> >>> help with the manual but will probably be quiet for a couple 
> >>> months as
> I
> >>> get adjusted in my new role as Content Strategist at Red Hat.
> >>>
> >>> If ever you're in my area let me know and we'll be sure to meet up 
> >>> in person!!
> >>>
> >>> Nicole
> >>> ___
> >>> Koha mailing list  http://koha-community.org 
> >>> Koha@lists.katipo.co.nz 
> >>> https://lists.katipo.co.nz/mailman/listinfo/koha
> >>>
> >> ___
> >> Koha mailing list  http://koha-community.org 
> >> Koha@lists.katipo.co.nz 
> >> https://lists.katipo.co.nz/mailman/listinfo/koha
> ___
> Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 16.05 Released

[Marcel de Rooy]

Congratulations. You made it !
Up to 16.11 ;)


Van: Koha  namens Brendan Gallagher 

Verzonden: donderdag 26 mei 2016 22:05:33
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Koha 16.05 Released

It is with great pleasure that we announce the release of Koha 16.05, a
major release of the Koha open source integrated library system.

Koha 16.05 is a major release, that comes with many new features and
enhancements.

See the full release notes here:
https://koha-community.org/koha-16-05-released/
Download http://koha-community.org/download-koha/
Debian Packages will soon be available in the repository.

Thank you to everyone who helped make this work!  Koha!!!


Please note – Ubuntu 16.04 support is still WIP and isn’t supported at the
moment, due to stricter MySQL version 5.7. All installs and updates should
be done on versions previous to MySQL 5.7.

Cheers,
Brendan

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

Support and Consulting for Open Source Software
Installation, Data Migration, Training, Customization, Hosting
and Complete Support Packages
Headquarters: Santa Barbara, CA - Office: Redding, CT
Phone # (888) 900-8944
http://bywatersolutions.com
i...@bywatersolutions.com
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Need assistance setting up SRU target

[Marcel de Rooy]

Hi Andy,
Does this SRU server also return marcxml ?
In your example it returns Dublin Core. Koha does (currently) not support it as 
input format.
Normally, you should recordSchema to specify the format.
Regards,
Marcel

Van: Koha  namens Andy Boze 
Verzonden: woensdag 6 april 2016 02:00
Aan: Koha list
Onderwerp: [Koha] Need assistance setting up SRU target

I'm hoping someone might be able to see what I'm doing wrong. I'm trying
to set up an SRU target for SwissBib. The SRU information for SwissBib
is at http://www.swissbib.org/wiki/index.php?title=SRU . (We're using
Koha v. 3.18.05.100)

I've used the SRU Explain function (
http://sru.swissbib.ch/sru/explain?operation=explain ) to get
information about search attributes.

In setting up the SRU target in Koha, I've used the following.

Hostname: sru.swissbib.ch
Port: 80
Database: sru/search/defaultdb
Syntax: UNIMARC
Encoding: utf8

Additional SRU options: operation=searchRetrieve
(I've tried using other SRU options, too, but this seems to be the
minimum required.)

SRU Search fields mapping:
Title - dc:title
ISBN - dc:identifier
Any - dc:anywhere
Author - dc:author
ISSN - dc:identifier
Standard ID - dc:id

The following URL will produce results in my web browser, but I get no
results when I do an equivalent SRU search in Koha.

http://sru.swissbib.ch/sru/search/defaultdb?query=+dc.anywhere+%3D+verne=searchRetrieve=10

Does anyone have any thoughts about what's wrong? Thanks in advance.

--
Andy Boze, Associate Librarian
University of Notre Dame
208 Hesburgh Library
(574) 631-8708
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 3.22.4 release

[Marcel de Rooy]

If only more languages had just one word :)

-Oorspronkelijk bericht-
Van: Koha [mailto:koha-boun...@lists.katipo.co.nz] Namens Julian Maurice
Verzonden: zondag 28 februari 2016 9:43
Aan: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] Koha 3.22.4 release

Le 28/02/2016 09:38, Julian Maurice a écrit :
> Good catch! The script that I used to generate this list of languages 
> was ignoring some languages (the ones with more than 2 words, 
> actually)

EDIT: The ignored ones were those with more than *one word*

--
Julian Maurice  BibLibre 
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Inactive patrons and fine forgiveness

[Marcel de Rooy]

Currently, we send two notices when membership expires (4 weeks to go and 1 
week to go).
We have a simple SQL report to capture all who expire with a link to delete 
them manually (some time after expiration).
Note that we have no fines (special library).


Van: Koha [koha-boun...@lists.katipo.co.nz] namens Chad Roseburg 
[croseb...@ncrl.org]
Verzonden: zaterdag 30 januari 2016 00:47
Aan: partn...@lists.bywatersolutions.com; koha@lists.katipo.co.nz
Onderwerp: [Koha] Inactive patrons and fine forgiveness

We are planning an amnesty program later this year ...early 2017 and would
like to know what other libraries are doing. First we'd like to purge our
inactive patrons.

I had a few questions for libraries that are doing this.

1. What are your policies for deleting patrons? Inactive ...expired ..etc?
1.2 What reports do you use to capture them?
1.3 What if they have fines?

2. What are (were) your policies for forgiving fines or fees?
2.2 How do you capture this info? [ what reports used? ]
2.3 What process do you use for clearing these?

Any advice or information you might have would be much appreciated!

Thank you!

--
Chad Roseburg
Automation Dept.
North Central Regional Library
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha upload failed

[Marcel de Rooy]

This definitely sounds like a permission problem on the temporary upload folder 
between those four koha instance users. Number 1 is the owner; 2, 3 and 4 can 
probably only read.
You can temporarily fix it by adding write permissions for those users. 

Note that bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14893 
should resolve this situation. Unfortunately it did not reach the 3.22 version..

Marcel


Van: Koha [koha-boun...@lists.katipo.co.nz] namens Hugo Agud [ha...@orex.es]
Verzonden: vrijdag 11 december 2015 11:11
Aan: Koha list
Onderwerp: [Koha] Koha upload failed

Good Morning

We're experiencing a strange problem with our public demo server on koha
3_22 plack activated and lso disabled and we wish to now if anybody else
has experience this problem and then open a bug  (we have not seen any bug
about this)

We are testing Koha 3.22.0 into a debian jessy server, we have created up
to four instances in the same server (instlled via packages) sudo
create.

We are experiencing problems when we upload a marc file into instance 2, 3,
and 4, but we have not problems upload the marc file into instance1.

the process is
tools-> import file when it uploads gives a message 'status
upload:failed'  no errors on log file, it seems some kind of permissions
problems to save the file into the server

Thanks you in advance!

--

*Hugo Agud - Orex Digital *

*www.orex.es *


  [image: http://orex.es] 



Director

Passatge de la Llançadera, 3 · 08338 Premià de Dalt - Tel: 93 539 40 70
ha...@orex.es · http://www.orex.es/



No imprima este mensaje a no ser que sea necesario. Una tonelada de papel
implica la tala de 15 árboles y el consumo de 250.000 litros de agua.



Aviso de confidencialidad
Este mensaje contiene información que puede ser CONFIDENCIAL y/o de USO
RESTRINGIDO. Si usted no es el receptor deseado del mensaje (ni
está autorizado a recibirlo por el remitente), no está autorizado a copiar,
reenviar o divulgar el mensaje o su contenido. Si ha recibido este mensaje
por error, por favor, notifíquenoslo inmediatamente y bórrelo de su sistema.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha vs Liblime Koha

[Marcel de Rooy]

 But I was looking at the LibLime version of Koha and wondered, out of
 curiosity, what problems I might run into if I installed their version
 instead of the current stable version as hosted on the community wiki.

You are asking this on the community list?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] A small gift from KohaCon14

[Marcel de Rooy]

Great !
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Cannot edit public list

[Marcel de Rooy]

See bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8262
Kohaadmin cannot create lists and should not create lists.
But the error from the log does not reach the interface. 
It is still on my list. Will work on lists this week.

Marcel

-Oorspronkelijk bericht-
Van: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] 
Namens Robin Sheat
Verzonden: zondag 2 maart 2014 23:05
Aan: koha
Onderwerp: Re: [Koha] Cannot edit public list

Marc Véron schreef op vr 28-02-2014 om 08:05 [+0100]:
 As far as I'm aware of the main task of the database user is to create
 user accounts (superlibrarians). Are there other tasks inside the
 staff
 client that should / must be done by the database user?

 Maybe we could turn off _all_ but such functions?

From a service provider point of view, the database user is very handy.
We use it to log in and look at things when we need to figure out why
something is working the way it is or to change a configuration option,
and we don't always have our own regular login to use. We could create
one, but we don't like to if we don't have to, as it has the potential
to confuse reports and such. This would get a lot harder if most options
were blocked.

There is a big warning at the top when you're logged in as the db user,
this ought to be enough (though the particular case here pre-dates that
warning.) I'm not averse to disabling known-bad things though, like
lists, and probably circulation. Or making the warning more prominent
perhaps.

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

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Cannot edit public list

[Marcel de Rooy]

Amy,
You are not encouraged to create public lists with the special Koha admin user.
Are you able to create a public list in staff, set the appropriate permissions 
on it, and add some items (logged in as a superlibrarian in staff) ?

Marcel

Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
Amy Schuler [schul...@caryinstitute.org]
Verzonden: dinsdag 25 februari 2014 22:02
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Cannot edit public list

Hello All,

In Koha admin interface, I am unable to add a record to a public list that
I created, using same user/password combo that I used to log in to Koha
admin.  I am able to view this public list (it still exists; was not
deleted), and I can edit my private list, but cannot edit the public list.
 Through the OPAC interface I have the same problem --- cannot add anything
to public list even though I can view its contents.

Details: When I am viewing a record, in either admin interface or OPAC, I
click on the Add To arrow and select LIST.  Where it says, select an
existing list -- there is no option.  If I am logged in under my personal
account, then I can add to my private list but there is still no public
list option.  Note that I have tried adding to the public list using both
my personal and admin logins, and yes, my personal login does have
superlibrarian permissions ( I double checked this).

I searched bugzilla and see no known bugs.

I am running Koha v.3.10.04.000

Any ideas are appreciated.  Thanks!

Amy Schuler
Cary Institute of Ecosystem Studies
Millbrook, NY
schul...@caryinstitute.org
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 3.14.0 released

[Marcel de Rooy]

Congratulations for this new release!

Marcel 


-Oorspronkelijk bericht-
Van: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] 
Namens Galen Charlton
Verzonden: donderdag 21 november 2013 5:49
Aan: Koha-List
Onderwerp: [Koha] Koha 3.14.0 released

Hi,

The Koha community is pleased to announce the release of version 3.14.0 of
the Koha library automation system.

Koha 3.14.0 is a major functionality release that includes various new
features, including:

* A new default theme, “Bootstrap”, for the public catalog interface. The
Bootstrap theme provides a reponsive design that works well both for
desktop web browsers and mobile devices.
* A new course reserves module.
* A new offline circulation module that is entirely browser-based.
* A revamp of the serials predication system which allows for significantly
more flexibility in managing patterns.
* The ability to create lists of patrons.
* The ability to search for items to check out by keyword rather than
barcode.
* The ability to overlay item records during batch imports.
* The ability to define rules (called MARC modification templates) for
batch-modifying MARC records during import.
* Numerous acquisitions workflow improvements, including the ability to
move orders from one vendor to another, search acquisitions history, merge
duplicate invoices, and get warnings if a new order would over-commit a
fund.
* Cataloging improvements including the ability to import authority record
via Z39.50, the ability to merge authority records, and the ability to save
and continue editing bib records.
* Support for schema.org microdata in the OPAC to increase the visibility
of your catalog to search engines.

There are also a number of under-the-hood improvements, including

* Zebra DOM filter support for UNIMARC bib and authority records.
* The introduction of an ORM, DBIx::Class.
* Significantly improved unit test coverage.

And, as always, there are numerous bugfixes and minor improvements.

Koha can be downloaded from http://download.koha-community.org. Debian
packages of Koha 3.14.0 will be available shortly.

As release manager for Koha 3.14, I would like to thank everybody who
contributed patches, documentation, testing, moral support, money, and time
to the effort. Koha users both old and new should find 3.14 a tasty piece
of π indeed.

Additional details, including the release notes, can be found at
http://koha-community.org/koha-3-14-0-released/

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

Re: [Koha] Don't pass out bad instructions (was Re: How frequently to run zebra rebuild and what switches)

[Marcel de Rooy]

 Just my unsolicited commentary on the provision of a really bad set of
 instructions on how to set Koha up.

Oops?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Data matching during MARC import

[Marcel de Rooy]

Hi Iming
Some bugs on Bugzilla deal with this need, felt in some libraries.
For instance: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921

Regards,
Marcel

-Oorspronkelijk bericht-
Van: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] 
Namens Iming Chan
Verzonden: donderdag 22 augustus 2013 15:14
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] Data matching during MARC import

Dear all,

Just wondering whether it is possible to use either 999$c or 999$d
(Biblionumber) as record matching mechanism during MARC import?

Currently, we are matching MARC records using 001 (Control number). 
However, every now and then, one of us forgot to manually add the Koha
biblionumber to 001 field after saving a new bibliographic record. 
Therefore, when we import MARC records, matches are not made (i.e.
fuller/higher quality records not replace brief ones created as part of the
acquisitions process).

It will be nice that the biblionumber can automatically added to MARC 001
tag when saving a new record.  Until then, we will have to save the record,
then edit the same record to manually enter the assigned biblionumber to
MARC 001 tag!!

Cheers,

Iming



-

Iming Chan
Translib Information Service
Melbourne, Australia
--
View this message in context: 
http://koha.1045719.n5.nabble.com/Data-matching-during-MARC-import-tp5765267.html
Sent from the Koha-general mailing list archive at Nabble.com.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Can't add items in public lists any more...

[Marcel de Rooy]

Good to hear that it worked. Yes, this is no perfect solution.

I will send some patches soon in the hope to improve this orphaned 
lists-problem.

Regards,

Marcel


Van: Sonia Padrun [sonia.pad...@anu.edu.au]
Verzonden: woensdag 22 mei 2013 4:54
Aan: koha@lists.katipo.co.nz; Marcel de Rooy
Onderwerp: Can't add items in public lists any more...

Dear Marcel and everyone else

Thanks for your help.  I am sorry I had some problems with my previous email 
address, that's why I use another one now.   But that's the same me who asked 
for help about the lists.  :)

First, sorry I forgot to mention our  koha version.  It is 3.10.05  (I know 
there is a new release, but well it will have to wait...).
Thanks to your help with the mysql queries, I managed to modify the access to 
these public lists and now we can add items again.  It is not perfect, as I 
would rather use an easy (not-geek) interface -- not being too shell friendly 
myself.  But still it works, and that's a great relief.

Now I will try to modify the list owner with the same kind of mysql queries.

Many many thanks!

Sonia.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Can't add items in public lists any more...

[Marcel de Rooy]

Sonia,
I can't make up the exact Koha version from what you write. So the following 
reply is based on some assumptions that could not be true..

Probably you are on 3.8.X or 3.10.X now. 
You say that this list is created by no one. I assume that this list has been 
created by a user that has been deleted from your system. In that case the 
owner becomes null (empty); use of the list is still governed however by the 
permissions defined for that list. Did your user try to add items without being 
logged in, for instance? When she logs in, can she see the list, add items or 
delete items? 

What we still need in Koha, is to change ownership for such lists. 
A quick and dirty way to recover this situation would need mysql access to the 
database.
If you have that or someone can do this for you, please check:
  select shelfnumber from virtualshelves where shelfname LIKE '%yourlistname%'
  *yourlistname should be substituted *
  use this number in the next mysql command: i called it yournumber
  select owner, allow_add, allow_delete_own, allow_delete_other for 
shelfnumber= yournumber
  if you have no error here, you are on 3.8
  i guess owner is null, but if the other values are 1, you should be able to 
use the list
  if not, try this:
  update virtualshelves set allow_add=1 where shelfnumber=yournumber

Hope this helps.
And keep an eye on further developments for lists..

Marcel

Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
Sonia P. [sossola...@hotmail.com]
Verzonden: maandag 20 mei 2013 4:19
Aan: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] Can't add items in public lists any more...

Dear all
Do you know if the lists owners could have changed with our recent Koha 
update?I have checked the Koha manual, I have googled whatever I could, I just 
can't find much information about these public lists.  How do we change the 
owner?  We have got a librarian here, she used to be able to add items in some 
lists (I am not sure whether she was the lists owner or not, but at least she 
could add items), no she can't.Also, I have just tried myself.  If I create a 
public list with everyone being allowed to do anything, then really it works, 
everyone can use it.  But we can't use any more the lists we used to use 
before, there is noone written in the created by column for these lists, and 
we don't know how to change that.  Another way of solving the problem for us, 
could be that I create new lists with everyone being allowed to use them again, 
and then export the contents of the old useless lists, but I can't find in the 
manual how to export / copy / paste / do-anything-really with
  the public lists.
Any help would be appreciated...
Cheers,
Sonia.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Bug: virtualshelves permisssion broken in staff client

[Marcel de Rooy]

 setting virtualshelves = 'don't allow' causes no changes in the staff client.
 users can still see the 'lists' option and create/view lists. virtualshelves
 = 'don't allow' should make completely remove lists from the staff client

I can understand your remark very well. 
What we still need in the staff client, is a permission that controls access to 
the Lists section. 
See also http://wiki.koha-community.org/wiki/List_permissions  Point 6

But do note that disabling pref virtualshelves still makes some difference: In 
catalogue search e.g. you will not be able anymore to see/add to  lists. 

Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Opac can't show non-latin characters correctly

[Marcel de Rooy]

I tested current master (3.11.00.202) with an author name containing Chinese 
character.
It displays fine in the facets column (Refine your search) at the left in opac 
as well as in staff.
Some relief with the recently pushed encoding patches for 6554 a.o. in mind :)

Marcel


Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
Fischer, Katrin [katrin.fisc...@bsz-bw.de]
Verzonden: dinsdag 23 april 2013 9:37
To: Peter Zhao; koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] Opac can't show non-latin characters correctly

Hi Peter,

the facets should work correctly with non-latin characters.
Which version of Koha are you using?
What is the problem you see?

Katrin

 -Original Message-
 From: koha-boun...@lists.katipo.co.nz [mailto:koha-
 boun...@lists.katipo.co.nz] On Behalf Of Peter Zhao
 Sent: Tuesday, April 23, 2013 8:22 AM
 To: koha@lists.katipo.co.nz
 Subject: [Koha] Opac can't show non-latin characters correctly

 Hi,

 Warmly greetings.

Could anyone know why in the Refine your search column area of OPAC
 can not show non-latin characters ? But in the other area of the OPAC can
 show non-latin characters. Anyone know how to fix this problem? Thanks a
 lot.

   Peter



 ___
 Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz
 http://lists.katipo.co.nz/mailman/listinfo/koha


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Why holds on restricted items?

[Marcel de Rooy]

Hi,

Does anyone know why I can place a hold on an biblio with items that have use 
restrictions (952$5 ) ?
You can even confirm the hold. So a mail goes out: Waiting for you.,etc.
But note that such items cannot be checked out.

What would be the use of placing and confirming holds on items you cannot check 
out?
Perhaps I am missing something? Did not see any reference in the manual either.


Regards,

Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Show responsibility statement (245c) under title and move authors down in OPAC XSLT

[Marcel de Rooy]

Hi all,



I added report http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9490 in 
Bugzilla for showing the responsibility statement under the title for opac 
detail and opac results.



If you would have any feedback on this, please add to the discussion under that 
report.



Thanks,



Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Cronjob

[Marcel de Rooy]

export KOHA_CONF and PERL5LIB  to the right Koha instance ? 


Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
MARC FELIX [billightn...@yahoo.co.uk]
Verzonden: zondag 13 januari 2013 14:02
To: Koha@lists.katipo.co.nz
Onderwerp: [Koha] Cronjob

Hi all, i have configured my cronjob for index new records as below.

*/5 * * * * $KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z /dev/null

The records are however not being indexed every after five minutes as i expect 
yet when i run /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -a -z on 
the terminal it indexes ok. What could be the problem?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] MySQL and year published

[Marcel de Rooy]

It is saved in two places: MARC 260c and the first year goes additionally to 
the Koha field as defined in marc_subfield_structure (kohafield). 
See the logic in Biblio.pm; search on copyrightdate. 

Marcel

-Oorspronkelijk bericht-
Van: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] 
Namens Paul
Verzonden: zondag 9 december 2012 23:40
Aan: koha@lists.katipo.co.nz
Onderwerp: [Koha] MySQL and year published

In all our frameworks we use 260$c for date of publication (mandatory -- even 
to the point of not known / n.k. so the field cannot be NULL.)

However, 260$c appears to be saved EITHER as biblioitems.publicationyear OR as 
biblio.copyrightdate and we do not have any records at all that include both; 
hence reports have to use e.g.

SELECT
IFNULL (biblio.copyrightdate,biblioitems.publicationyear) AS Year,

I get the impression (but am far from certain) that biblioitems.publicationyear 
was used in Koha 3.6 and biblio.copyrightdate is used in 3.8

Maybe one of you who was involved in the update data tables scripts (which I 
have always found to work satisfactorily) could help me?  Is there any reason 
not to copy publicationyear to the copyrightdate? Is 
biblioitems.publicationyear still used in 3.8? SchemaSpy does not appear to 
answer this question (although publication year is given as text, 65535; 
copyrightdate as smallint, 5) and while the data transfer went well in my 
sandbox, I hesitate to do this in production in case there are side effects.

The reason for my doubts is that a smallint should not be able to save e.g. 
 [c1974?]  but Koha does save it while MySQL reports purely 1974 ... so where 
is the text saved?

Many thanks and best regards,
Paul

___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Removal from list of Koha vendors

[Marcel de Rooy]

Thanks for your work!

Marcel

-Oorspronkelijk bericht-
Van: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] 
Namens Koustubha Kale
Verzonden: maandag 26 november 2012 10:38
Aan: Koha list
Onderwerp: [Koha] Removal from list of Koha vendors

Hi all,
It has been my privilege and pleasure to have worked on Koha. Through the 
great, friendly Koha community I have gained knowledge and friends throughout 
the world. I hope these bonds of friendship will continue in the future. And 
that I will get a chance to work with Koha once again. It is with great sadness 
I say that Anant Corporation partnership firm has been dissolved  it no longer 
provides support for Koha or any other software for that matter. Request you to 
please remove it from the list of Koha vendors.

Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address  : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane 
(w),
Maharashtra, India, Pin : 400601.
Mobile : +919820715876
___
Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz 
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Lists; needed features, including location and staff level sharing

[Marcel de Rooy]

Hi Elaine
In one or two days I will put a patch on Bugzilla that displays call number for 
lists in staff, including the ability to sort on item call number (with the 
limitation that it sorts on the first item). We use that now. 

Another future development is Sharing a list. The foundation is already in 
Koha. (See BZ 7310). It would cover your need of sharing a list between staff 
members. A shared list is a private list that can be accessed by designated 
others too with the specified lists permissions already present in Koha. 

Actually I already share lists between staff members, but this needs the 
following sql. (Do not know if you are comfortable with that. A developer 
should understand what to do.. )
insert into virtualshelfshares (shelfnumber, borrowernumber) VALUES (?, ?);
You only need to pass the right shelfnumber and designated borrowernumber for 
the user that is not the owner, but permitted to use the list.
Note that altough it works (for me), this is still experimental.  

Marcel


Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
Elaine Bradtke [e...@efdss.org]
Verzonden: maandag 5 november 2012 20:36
To: koha
Onderwerp: [Koha] Lists;needed features, including location and staff 
level sharing

We use 3.8 and are trying to enable our users to make more independent use
of the catalog (instead of relying on the staff to look everything up, as
they did  in our old system).

On the public service side, I can see at least two important uses for lists:
1) For staff to create mini-bibliographies for topics in high demand.
2) For patrons to choose what material they would like to consult - a
shopping list as it were (and quite often, this list will be passed on to
the staff, because they will need to retrieve some items from other
locations).

But, once you create a list, the printout is not very useful.
In the OPAC, the list gives title, author, publishing
info, availability and call number. Theoretically one could print out the
list and then wander around the stacks fetching the items.

But there's a  serious flaw in the system.  The list in the OPAC version,
does not show the shelving location.  Since only about a quarter of our
collection is on open shelves (and some of it is located by size)  this
means the reader is going to get  very frustrated. We have not included
location information as part of the call number, as it can and does change,
and would potentially complicate the browse the shelves feature.

Imagine my surprise and disappointment when I discovered that the Staff
interface view of the same lists gives substantially less (rather than
more) information.

If our staff needs to collect material from store rooms and locked cases,
they have to print out individual records.  This is actually a step
backwards from our old database, where we could print out a list with the
retrieval information for each item.


We've disabled the Cart function, so I don't know if that is any worse or
better.  If it will show location, I will re-enable it.


My second difficulty is the public / private  settings for lists.  It would
be very useful to have a third choice: Staff only.
Sometimes a list is a collaborative work, in progress, not ready (or
intended) for public consumption, but more than one person needs access to
it.
Sometimes a list is useful for communicating with other staff members (we
are rarely all in the same place at the same time)
I designed some templates with default text for the staff to use for
specific types of material, and I don't want these to be seen by the
public, but if I make them private, then the staff can't see them either.


Are solutions to the above problems in the pipeline for future versions of
Koha? Or should I file a bug/enhancement?

Thanks,


--
Elaine Bradtke
Data Wrangler
VWML
English Folk Dance and Song Society | http://www.efdss.org
Cecil Sharp House, 2 Regent's Park Road, London NW1 7AY
Tel+44 (0) 20 7485 2206 (This number is for the English Folk Dance and
Song Society in London, England. If you wish to phone me personally, send
an e-mail first. I work off site)
--
Registered Company No. 297142
Charity Registered in England and Wales No. 305999
---
Writing about music is like dancing about architecture
--Elvis Costello (Musician magazine No. 60 (October 1983), p. 52)
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] DOM versus GRS-1

[Marcel de Rooy]

 Shortly afterwards we noticed that there was quite a few biblios not 
 appearing on the search results even though they exist in the database.
 After trying many, many things I decided to switch from DOM to grs-1 and 
 rebuild the indexes. This has resolved the problem and the search results are 
 now correct. Switching back to DOM brings back the problem.
 Does anyone know why this might be the case - broadly speaking. Should DOM 
 and grs create the same index result set by using different filters or are 
 these types of differences expected?

I have the impression that not all indexes in grs1 have a counterpart yet in 
dom. My hit counts are not that high under dom as they are in grs1.
We should add them gradually under dom, because the idea is to leave the older 
grs1. 

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Authority indexing

[Marcel de Rooy]

Hi,
Below a fragment from a discussion on authority indexing on the dev list. 
As a developer, I would like to get some specific librarian feedback on this 
list.

 Another thought to add to the discussion: If we need the difference between 
 searching through main headings, all subfields and main headings $a only, why 
 do we not present these four identical options in opac and staff? It seems 
 overkill to me, but please speak up if you need one of the two !

Do you (your library) make good use of searching authorities in staff client? 
There are three searches there.  Note that the first one (Search authorities) 
only looks in heading $a subfields.  Do you need the difference when searching 
authorities between $a only or all subfields?  Would you need the other one: 
headings, all subfields? 

Hope I am being clear enough .. 

Thanks,
Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Bugzilla Installation List

[Marcel de Rooy]

Hi Gerv,



Was just checking the list of installations on Bugzilla. As a member of the 
Koha community, I just noticed that our Bugzilla installation is not listed 
correctly anymore (probably for some time already).



Bugzilla for open source Koha is found here:  http://bugs.koha-community.org/

The Koha open source community site is http://koha-community.org



The two currently listed URLs refer to Liblime Koha. One of them is not working.



Could you please adjust the listing? I am copying the Koha mailing list and 
Liblime Koha. If they still use Bugzilla, they may probably respond for 
themselves also.



Thanks,



Marcel


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] FW: Your message to Liblimekohadiscussion awaits moderator approval

[Marcel de Rooy]

:-)


Van: liblimekohadiscussion-boun...@lists.liblime.com 
[liblimekohadiscussion-boun...@lists.liblime.com]
Verzonden: vrijdag 2 maart 2012 12:05
To: Marcel de Rooy
Onderwerp: Your message to Liblimekohadiscussion awaits moderator approval

Your mail to 'Liblimekohadiscussion' with the subject

Bugzilla Installation List

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


http://lists.liblime.com/cgi-bin/mailman/confirm/liblimekohadiscussion/70c859ea27e9aa2c63e384de0dcceb7755f1cb57
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Hi all,
Following up on the discussion on list permissions in December, I updated the 
wiki page http://wiki.koha-community.org/wiki/List_permissions and submitted 
the first patches for report 7310 
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7310)

These first patches form the foundation for further changes but still stay very 
close to current functionality.

One new point (not discussed before): While developing and refactoring some 
code, I removed the increasing lists information from session storage. This 
simplified the code, makes the sessions much smaller, ensures actual list 
information and did not make a big difference in performance (depending on 
factors as session count, number of lists, etc.; could even be faster).

Next step in the development is now test and sign-off. Anyone willing is 
welcome to test! A detailed test plan is included on the report and on the wiki.

Hope to hear from you!

Marcel


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] [Discussion tech] Generalise the use Template Toolkit plugins

[Marcel de Rooy]

I would say here that a general rule is hard to make. Even disapproving a patch 
only for the reason of not using a plugin is discussionable.  Current Koha 
does a lot of things in a lot of ways. Standardizing with routines and plugins 
is a continuous educational project..


Van: koha-devel-boun...@lists.koha-community.org 
[koha-devel-boun...@lists.koha-community.org] namens Paul Poulain 
[paul.poul...@biblibre.com]
Verzonden: vrijdag 10 februari 2012 12:24
To: koha-de...@lists.koha-community.org; Koha-Mailinglist
Onderwerp: [Koha-devel] [Discussion tech] Generalise the use Template Toolkit   
plugins

I've started another discussion page:
http://wiki.koha-community.org/wiki/Generalise_the_use_Template_Toolkit_plugins

Chris_c recently has added a plugin to manage the display of dates into
Koha (see
http://wiki.koha-community.org/wiki/Coding_Guidelines#Displaying_dates),
that is very interesting.

Do we want to generalise this mechanism ? When do we want to use it ?

For example, the patch for bug
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 could
nicely use this mechanism

let's start the discussion !
(reading the page and the possible solutions, you'll see I made 2, but
am not happy with them. Probably need others ideas...)
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
___
Koha-devel mailing list
koha-de...@lists.koha-community.org
http://lists.koha-community.org/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 mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] OPAC MARC View display not working well

[Marcel de Rooy]

Report 6829 and follow-ups may be relevant here? (Problem with 0XX fields.)


Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
Ian Bays [ian.b...@ptfs-europe.com]
Verzonden: vrijdag 3 februari 2012 11:26
To: Mason James
Cc: koha@lists.katipo.co.nz
Onderwerp: Re: [Koha] OPAC MARC View display not working well

Yes.  Even exporting the odd record from the 3.6.1 and importing to the
3.6.2, the display on the 3.6.2 does not fail.  I thought we might have
broken the xsl stylesheet, but turning that off still loses those tags
(020, 099, 245, 300, 650).  Will report what we find - however
embarrassing...
Ian

On 03/02/2012 00:52, Mason James wrote:
 On 2012-02-2, at 11:33 PM, Ian Bays wrote:

 I believe (prompted by the original post) we are seeing this issue on 
 version 3.06.01.000.


 We have a system at version 3.06.02.003 which had no bib data on it but 
 importing a record and viewing in OPAC MARC view,
 the problem does not seem to be there any more.
 so its broken in your 3.6.1 Koha?,  but fixed in your 3.6.2 Koha?

 Ian

--
Ian Bays
Director of Projects, PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7774 995297 (mobile)
+44 (0) 800 756 6384 (fax)
skype: ian.bays
email: ian.b...@ptfs-europe.com

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Problem when removing subfield in biblio editor

[Marcel de Rooy]

Hi,

Does anyone of you recognize this (rather serious) problem.

If I have a field say 710 with $4 relator code followed by $9 authid and $a 
name, and I clear the $4 with Delete this subfield and save the record, I also 
loose the other subfields!!

This does not happen when the subfield order is different like $9 $a $4 and 
clearing $4.



Came across old Bugzilla reports 3264 and 5707 but they seem to focus on 
authorities editor. This problem above is in the biblio editor.



Any comments welcome,



Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Experience with msyql setup for utf-8

[Marcel de Rooy]

[mysqld]
default-character-set=utf8
character-set-server=utf8

[mysql]
default-character-set=utf8

[client]
default-character-set=utf8


If you change conf file, please restart service (of course..)


 -Oorspronkelijk bericht-
 Van: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz]
 Namens Zeno Tajoli
 Verzonden: donderdag 22 december 2011 12:48
 Aan: koha@lists.katipo.co.nz
 Onderwerp: [Koha] Experience with msyql setup for utf-8
 
 Hi to all,
 
 I'm checking the setup of a new Koha site, and I'm sure that we will
 deeply use UTF-8.
 
 In /etc/mysql/my.conf, section [mysqld] I have insert:
 init-connect = 'SET NAMES utf8'
 character-set-server=utf8
 collation-server=utf8_general_ci
 character_set_client=utf8
 
 In fact is what is written here:
 http://wiki.koha-community.org/wiki/Encoding_and_Character_Sets_in_Koha
 
 Well, if I do a check on mysql with root user I see:
 mysql show variables where variable_name LIKE character_set% OR
 variable_name LIKE collation%;
 +--++
 | Variable_name| Value  |
 +--++
 | character_set_client | latin1 |
 | character_set_connection | latin1 |
 | character_set_database   | utf8   |
 | character_set_filesystem | binary |
 | character_set_results| latin1 |
 | character_set_server | utf8   |
 | character_set_system | utf8   |
 | character_sets_dir   | /usr/share/mysql/charsets/ |
 | collation_connection | latin1_swedish_ci  |
 | collation_database   | utf8_general_ci|
 | collation_server | utf8_general_ci|
 +--++
 
 I use msyql 5.1 on Debian
 
 Do you think is a coerent situation ?
 
 Which experience do you have with mysql utf-8 setup ?
 
 Bye
 Zeno Tajoli
 
 --
 Dott. Zeno Tajoli
 tajoliAT_SPAM_no_prendiATcilea.it
 fax +39 02 2135520
 CILEA - Consorzio Interuniversitario
 http://www.cilea.it/disclaimer
 ___
 Koha mailing list  http://koha-community.org
 Koha@lists.katipo.co.nz
 http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Thanks all for responding to this inquiry. This was very helpful.



I am merging here the results and will be posting them back to report 7310 or a 
wiki page. Feel free to correct me where I made the wrong conclusion.



1 Public lists in OPAC: Currently, a user should be logged in to create a list. 
I would strongly recommend to keep that restriction. A new preference is added 
that allows opac users to create public lists or does not allow that.

Additionally, I would add the restriction that another opac user cannot change 
the list type of a public list to private list or change the list permissions 
when he did not create it (currently possible); the owner can do that or a 
staff member with permissions in the staff client.



2 Three new permissions per list: Add items, Delete own items, Delete other 
items. This makes the Open list type obsolete.



3 Share private lists with another patron (as described before). Can be turned 
on/off with a preference.



4 Staff client features: add an option under Tools to moderate inappropriate 
list names for public lists and shared private lists. (A library is free to use 
it or not.) Add staff list permission: allow to manage lists (virtual shelves). 
With that permission a staff member can moderate the list names as mentioned 
and access the staff Lists module. (He can change list type and permissions. He 
can take ownership of a public list if the owner has been deleted.)



5 [NEW] Deleting a patron should also delete his (unshared) private lists, his 
shares with private lists of someone else and clear owner on his public lists. 
[Currently, the virtualshelves table will contain lists (of any type) of 
deleted borrowers.]

A new problem is what to do with shared private lists (still used by other 
patrons).

Just deleting them would not be nice for those patrons. Just promoting them to 
public lists could not be ideal too; same for leaving this to be sorted out by 
the librarian. The best [pragmatic] solution is probably setting ownership to 
the first user that received a share on that list. (He already had access to 
those lists, but is now able to change settings on that list too.)



ADDITIONAL COMMENT

If a library does not allow public list creation in OPAC and does not share 
lists, how should a staff member change list type of a private list? This is 
not possible. You could say by design. It is the result of combining those two 
prefs. As a workaround, a staff member could enable public list creation, let 
the user change list type in opac and reset the pref. Or enable sharing lists, 
let the user share that list with staff member, accept it and reset the pref.


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Your presentation looks very good. (But seems to me also a matter of 
customizing css.)
You mention subcategories: how did you do that in terms of functional/technical 
design ?


Van: Adalid Ortiz [ada...@tij.uia.mx]
Verzonden: woensdag 7 december 2011 20:47
Aan: Marcel de Rooy; koha@lists.katipo.co.nz; 
koha-de...@lists.koha-community.org
Onderwerp: Re: [Koha] Improving permissions on lists (virtual shelves)

Excellent but I want to add a useful feature, list categories and subcategories 
like in this Koha fork called Estantes virtuales:

http://biblioteca.exactas.unlp.edu.ar/cgi-bin/koha/opac-shelves.pl?startfrom=0


Saludos,

Felipe Adalid Ortiz Anzaldo
Bibliotecario de sistemas
Universidad Iberoamericana Tijuana
Biblioteca Loyola
http://clavius.tij.uia.mx
Ave. Centro Universitario 2501
Playas de Tijuana
22200, Tijuana, B.C.
0 664 630-1577 Ext. 623
ada...@tij.uia.mx

En una jerarquía, el poder lo tiene quien guarda secretos; en una red el poder 
lo obtiene quien disemina información”.
-John Perry Barlow-
Subject: Re: [Koha] Improving permissions on lists (virtual shelves)
   From: Marcel de Rooy m.de.r...@rijksmuseum.nl
   Date: Wed, 7 Dec 2011 16:08:58 +
 To: koha@lists.katipo.co.nz koha@lists.katipo.co.nz,
   koha-de...@lists.koha-community.org 
 koha-de...@lists.koha-community.org

--===0312935277==
Content-Language: nl-NL
Content-Type: multipart/alternative;
   boundary=_000_809BE39CD64BFD4EB9036172EBCCFA3137F0B6SMAIL1Brijksmuseu_

--_000_809BE39CD64BFD4EB9036172EBCCFA3137F0B6SMAIL1Brijksmuseu_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks all for responding to this inquiry. This was very helpful.



I am merging here the results and will be posting them back to report 7310 =
or a wiki page. Feel free to correct me where I made the wrong conclusion.



1 Public lists in OPAC: Currently, a user should be logged in to create a l=
ist. I would strongly recommend to keep that restriction. A new preference =
is added that allows opac users to create public lists or does not allow th=
at.

Additionally, I would add the restriction that another opac user cannot cha=
nge the list type of a public list to private list or change the list permi=
ssions when he did not create it (currently possible); the owner can do tha=
t or a staff member with permissions in the staff client.



2 Three new permissions per list: Add items, Delete own items, Delete other=
 items. This makes the Open list type obsolete.



3 Share private lists with another patron (as described before). Can be tur=
ned on/off with a preference.



4 Staff client features: add an option under Tools to moderate inappropriat=
e list names for public lists and shared private lists. (A library is free =
to use it or not.) Add staff list permission: allow to manage lists (virtua=
l shelves). With that permission a staff member can moderate the list names=
 as mentioned and access the staff Lists module. (He can change list type a=
nd permissions. He can take ownership of a public list if the owner has bee=
n deleted.)


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Hi all,

Still hoping to get some feedback on this subject, I would now propose the 
following. Please respond to the list, if you agree or disagree. 

1  Do not allow to create a public list in the OPAC. (Only private lists.)  
Public lists are only created by staff users in the staff client. 
2  Add three permission options to any list: a) Allow adding entries b) Allow 
deleting your own entries (that you added)  and c) Allow deleting entries that 
someone else added.
   This makes the distinction between public list and open list no longer 
needed and adds some refinement in lists management. 
   Only the owner of the list can change these permissions.
3  Add a new (opac) feature to private lists: Share a list (with another 
patron).
   Let the user share access to a list by Koha sending an email with a URL 
including some (temporary) invitation key. When the invited patron clicks that 
URL (when logged in) he gains access (in accordance with the described 
permission options for that specific list).
   The invited patron can always 'delete' the shared list, i.e. delete the 
share.
   The owner can 'unshare' the list and remove all shares for that list.
4  With respect to user privacy, a feature may be added in staff client to 
moderate shared list names. 
5  Possibly, libraries do not want patrons sharing lists. So the option could 
be disabled with a preference. In that case points 2 and 3 still apply. 

Note that the shared private list concept makes report 7281 (Hiding some lists) 
obsolete.
Bug 7310 will be used for this feature.

Your comments are very welcome! 

Marcel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Point 4: An option like Moderate patron comments just to modify shared list 
names that would be inappropriate, insulting, etc. (since the list name is no 
longer private but visible to other users/patrons). 

 -Oorspronkelijk bericht-
 Van: Zeno Tajoli [mailto:taj...@cilea.it]
 Verzonden: maandag 5 december 2011 12:05
 Aan: Marcel de Rooy
 CC: koha
 Onderwerp: Re: [Koha] Improving permissions on lists (virtual shelves)
 
 Hi to all,
 
 Il 05/12/2011 11:42, Marcel de Rooy ha scritto:
  Still hoping to get some feedback on this subject, I would now propose the 
  following.
 Please respond to the list, if you agree or disagree.
 
  1  Do not allow to create a public list in the OPAC. (Only private lists.)  
  Public lists are
 only created by staff users in the staff client.
  2  Add three permission options to any list: a) Allow adding entries b) 
  Allow deleting
 your own entries (that you added)  and c) Allow deleting entries that someone 
 else
 added.
 This makes the distinction between public list and open list no longer 
  needed and
 adds some refinement in lists management.
 Only the owner of the list can change these permissions.
  3  Add a new (opac) feature to private lists: Share a list (with another 
  patron).
 Let the user share access to a list by Koha sending an email with a URL 
  including
 some (temporary) invitation key. When the invited patron clicks that URL 
 (when logged
 in) he gains access (in accordance with the described permission options for 
 that
 specific list).
 The invited patron can always 'delete' the shared list, i.e. delete the 
  share.
 The owner can 'unshare' the list and remove all shares for that list.
  4  With respect to user privacy, a feature may be added in staff client to 
  moderate
 shared list names.
  5  Possibly, libraries do not want patrons sharing lists. So the option 
  could be
 disabled with a preference. In that case points 2 and 3 still apply.
 
  Note that the shared private list concept makes report 7281 (Hiding some 
  lists)
 obsolete.
  Bug 7310 will be used for this feature.
 
 I think that this RFC is a good develop about virtual shelves.
 Total OK on point 1.
 In my opinion i prefer not to use 'sharing lists' so for me point 5 is
 quite important.
 I don't understand very well why point 4.
 
 Cheers
 Zeno Tajoli
 
 
 
 --
 Dott. Zeno Tajoli
 tajoliAT_SPAM_no_prendiATcilea.it
 fax +39 02 2135520
 CILEA - Consorzio Interuniversitario
 http://www.cilea.it/disclaimer
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Thanks, Brooke. We could/should make it possible to upgrade a private list to a 
public list in staff client. 
Do you have an idea where the user in opac could do such a request to staff? 
Just an email or something else? Or: Share it with staff?

 -Oorspronkelijk bericht-
 Van: BWS Johnson [mailto:abesottedphoe...@yahoo.com]
 Verzonden: maandag 5 december 2011 12:01
 Aan: Marcel de Rooy; koha
 Onderwerp: Re: [Koha] Improving permissions on lists (virtual shelves)
 
 Kia ora!
 
 
  1  Do not allow to create a public list in the OPAC. (Only private lists.)
  Public lists are only created by staff users in the staff client.
 
 
     I'm still struggling with this. While I realise that some Patrons who 
 shall remain
 nameless and spammers might create stuff we don't want floating round the 
 OPAC,
 some of the best bibliographies are created by Patrons, not Staff. I feel 
 like at the
 bare minimum, there needs be a way for a Patron to send their list to Staff 
 to be
 made public. I like just giving them the ability to make lists public better, 
 though.
 
 Cheers,
 Brooke

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

4  With respect to user privacy, a feature may be added in staff client to 
moderate shared list names.

Right now patron names don't show on lists at all - not sure if we need them 
really.

I do not mean patron names, but the list name itself could be problematic and 
needing moderation.
Thanks for your comments.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

1  Do not allow to create a public list in the OPAC. (Only private lists.)  
Public lists are only created by staff users in the staff client.

I think this should be a preference that the librarians can choose from the 
following options :

   1. Allow anyone to create public lists without moderation
   2. Allow patrons to create public lists with moderation
   3. Allow only staff (with permission) to create public lists

Brooke came up with an idea where the patron asks staff to upgrade a private 
list to a public list or so..
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

  4  With respect to user privacy, a feature may be added in staff client to 
  moderate
 shared list names.
 
 Do we propose to moderate the names of lists which users want to make
 public, or lists which users want to share with others (option 3)?

Thanks.
My idea is: Do not moderate private list names, but optionally do so for shared 
private and public lists (visible for 1 patrons).

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] [Bug 7310] Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Hi,
If you have a suggestion on report 7310 about lists management, please respond.

Following up on report 7281 (hide lists from OPAC) I am sending the following
question to the ml in order to improve lists management:

1 Who should be allowed to delete a public [closed] list (category 2 only!) or
add/remove items from that list? (Note that removing all items from a list is
more or less the same as removing the list at once.)
My answer would be: the owner should only be allowed to do that in the OPAC. A
user in the staff client may do it too.
[Currently, any opac login can delete the list. This is a bug!]

2 Who should be allowed to delete an public open list (category 3 only!) or
add/remove items from that list?
My answer would be: any login from OPAC or staff. It should be made clear that
creating such a list is really at your own risk ;) Currently, a user in the
opac cannot create an open list. (Is that a bug?)

3 Proposed revisions to lists management:
If we solve points 1 and 2, management of lists comes down to all or nothing.
You can do everything with an open list, but if you are not owning a closed
list, you can't do anything. Would it be useful to have something in between?
Like deleting your own added items from a closed list (we could save
borrowernumber in virtualshelfcontents)?? Or give the owner of an open list the
choice between full access for other logins, adding items only or deleting own
added items?
What do you think?

Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] 7310 Improving permissions on lists (virtual shelves)

[Marcel de Rooy]

Somehow I wonder if this message came through on the Koha list today. Resending 
it: 


Hi,
If you have a suggestion on report 7310 about lists management, please respond.

Following up on report 7281 (hide lists from OPAC) I am sending the following
question to the ml in order to improve lists management:

1 Who should be allowed to delete a public [closed] list (category 2 only!) or
add/remove items from that list? (Note that removing all items from a list is
more or less the same as removing the list at once.)
My answer would be: the owner should only be allowed to do that in the OPAC. A
user in the staff client may do it too.
[Currently, any opac login can delete the list. This is a bug!]

2 Who should be allowed to delete an public open list (category 3 only!) or
add/remove items from that list?
My answer would be: any login from OPAC or staff. It should be made clear that
creating such a list is really at your own risk ;) Currently, a user in the
opac cannot create an open list. (Is that a bug?)

3 Proposed revisions to lists management:
If we solve points 1 and 2, management of lists comes down to all or nothing.
You can do everything with an open list, but if you are not owning a closed
list, you can't do anything. Would it be useful to have something in between?
Like deleting your own added items from a closed list (we could save
borrowernumber in virtualshelfcontents)?? Or give the owner of an open list the
choice between full access for other logins, adding items only or deleting own
added items?
What do you think?

Marcel
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] cleanup_database.pl

[Marcel de Rooy]

Include the --sessions parameter too.
I agree with you that this should be improved. 
Will send a patch for that next week.


Van: koha-boun...@lists.katipo.co.nz [koha-boun...@lists.katipo.co.nz] namens 
Tom Hanstra [t...@nd.edu]
Verzonden: donderdag 13 oktober 2011 21:46
Aan: Koha listserv
Onderwerp: [Koha] cleanup_database.pl

I'm not sure if this is a bug or a problem in how I'm running the
clean_database.pl script...

Running the script, it says the sessions are going to be purged:

$ PERL5LIB=$PERL5LIB $KOHA_CRON_PATH/cleanup_database.pl -v --sessions
--sessdays 2
Session purge triggered with days2.
0 sessions were deleted.
Done with session purge with days2.

But there are sessions older than 2 days:

mysql select * from sessions;
| 0ea4915d23eff57160797fdd1d55 | ---
_SESSION_ATIME: '1315496500'
_SESSION_CTIME: '1315496500'
_SESSION_ID: 0ea4915d23eff57160797fdd1d55
...

and Unix time stamp '1315496500' translates to 'Thu, 08 Sep 2011
15:41:40 GMT'.

Did I miss something??

Tom

--

-
  Tom Hanstra  Systems Administrator
  Hesburgh Libraries of Notre Dame Phone: (574)631-4686
  213 Hesburgh Library Email: t...@nd.edu
  Notre Dame, IN  46556

 Please stop, I'm bored.
Miss Sweetie Poo
-

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] FW: Commentary on Paul's Koha 3.8 Release Manager proposal

[Marcel de Rooy]

I think both proposals (from Paul and Ian) contain very good points, are 
ambitious and motivating for the community. With people like Ian and Paul in 
the release team, we will definitely reach a Koha 4.0! 

I would however not favor working in parallel on Koha 3.8 and 4.0 as well as 
maintaining 3.6.X (and possible even 3.4.X for a while). I think that three or 
four versions together with lowering quality standards will not result in a 
better product, but could imply more bugs, rebasing problems and time lost on 
synchronizing between versions, testing in multiple versions, etc. 
Why not keep it simpler? Develop in master (heading to 4.0 and solR), and keep 
3.6.X stable (as soon as 3.6.X is there, declare 3.4.X end-of-life too). Just 
focus on those two versions.

A long feature list for 4.0 is very nice and Ian's development plan may 
theoretically be the best way to go, but probably hard to realize in practice. 
A simpler approach would be: as soon as solR and searching is ready and stable, 
we reach 4.0. This could be after 3.8, 3.10, .. (Stick to the 6m cycle.) 

We have been growing into a higher QA standard when we came from 3.2. I think 
it would be a pity if we already lower that standard too quickly. A problem is 
obviously the longer time between submission and pushing. Probably, we could 
improve in that area by adding some persons at the QA level (Ian may have two 
assistants in 3.8?), asking the bug wranglers to test older patches first and 
let them communicate more about these patches, and doing QA first on these 
older signed patches. Currently, time does not really rule selection of a patch 
in signoff or QA, but other factors like author, size, attractive title, etc.  
At the same time we could allow people perhaps to sign the more easy, trivial 
patches themselves (especially if they have them running in production already 
somewhere). If QA would disagree, they could lower the patch status back to 
Needs signoff for getting another external test. We could make a proposal how 
to change current procedures for this without compromizing quality. 
What we should avoid, is large, very large patches without test plan. These 
patches did not come through now too. Which is quite understandable. Such 
patches should be broken up into manageable units with a test plan.

Hope this helps,

Marcel

 Everyone,
 
 
 Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release
 Manager.  The details of his document can be found here:
 http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38
 
 I thoroughly agree that the time has come to start thinking beyond the
 next stable release, and on to Koha 4.0.  Those of you who have seen
 either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know
 I'm very excited about the possibilities of where we can take Koha in
 it's next major iteration.  However, I disagree with a couple of the
 details of Paul's proposal.
 
 The major disagreement is with the timeline.  The proposal as it stands
 is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8
 releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I feel that
 going from Koha 3.8 directly to 4.0 is unwarranted.  To my mind, there
 are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14
 and so forth.  This is supported by the actual database version numbers
 in Koha: the current release is actually 3.04.04; the zeros are squashed
 out for convenience.
 
 I would counter that, while we should continue releasing new features
 every 6 months on the 3.X line, Koha 4.0 should be defined by it's
 features.  Paul's proposal calls several features to be key, including
 Solr integration, database abstraction, updated online help, improved
 authentication stack and automated tests.  I agree that all these things
 are important and should be worked towards, but I'm not convinced they
 should be the sum total of the changes that define Koha 4.0
 
 I would like to see the following in Koha 4.0:
 
 * arbitrary metadata formats (beyond MARC)
 * arbitrary biblio relationships
 * full support for authority records, including uploading through
   the GUI, automatic linking, explode searching and more
 * improvements to the borrower data structure (fewer pre-defined
   data fields, more flexibility)
 * separation of receiving and payment in acquisitions
 * serials import and export (MFHD, prediction patterns, etc)
 * many, many more things
 
 I think that the community should meet and discuss what features are
 both desirable and reasonably likely to be completed in the next few
 years (is there interest by libraries to sponsor these developments, or
 from developers to code it for fun?).
 
 Once a feature set is agreed on to define Koha 4.0, the developers of
 these features would meet to hash out what underlying structural changes
 would be required to make them happen.  Hopefully commonalities could be
 found, so that the