Re: [Koha] KOHA DOWNGRADE

[Pablo Bianchi]

This would stop the major upgrades, which is different of a downgrade:

sudo sed -i_BAK-$(date -I) "s/oldoldstable/23.05/"
/etc/apt/sources.list.d/koha.list
___

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

Re: [Koha] Analytical cataloguing causing a searching warning

[Pablo Bianchi]

Hi Aleisha,

I came across this issue recently (v21.05.09). Everything seemed to work
fine, jumping from host to analytic records back and forth. Using Zebra, so
the bug 29284
 isn't
probably related. The error message showed up on the analytical record.
Using UseControlNumber=Use, EasyAnalyticalRecords=Don't display. Removing
subfields of 773 had no effects.

The solution/workaround was to add a control number/001 to the analytical
record (the host already had). Why this works? No idea.

Regards,
Pablo


On Mon, 14 Feb 2022 at 22:05, Aleisha Amohia 
wrote:

> Hi Koha community!
>
> We're having some trouble with analytical cataloguing - linking host and
> child records.
>
> We have EasyAnalyticalRecords enabled, and UseControlNumber disabled.
> When we link the host item using the barcode, the detail page for the
> child item shows this warning above the title: "There was an error
> searching for analytic records, please see the logs for details."
>
> The Plack Intranet error log shows the following errors:
> [2022/02/15 13:59:09] [WARN] CCL parsing error (10014) Embedded
> truncation not supported ZOOM for query: Host-item=(BIBLIO_TITLE /) at
> /usr/share/koha/lib/C4/Search.pm line 241.
> [2022/02/15 13:59:09] [WARN] Warning from simple_search_compat: CCL
> parsing error (10014) Embedded truncation not supported ZOOM at
> /usr/share/koha/intranet/cgi-bin/catalogue/detail.pl line 152.
>
> I have tried also manually linking the host item by cataloguing directly
> into the 773 of the child item, the searching warning still shows.
>
> I have also tried enabling UseControlNumber and putting the 001 of the
> host record into 773$w of the child item, which has usually worked (the
> warning disappears), however this method does not work for us because
> the library doesn't usually fill in the 001. We'd rather keep
> UseControlNumber disabled.
>
> Is this a problem that other libraries have other seen?
>
> Have you been able to solve it while keeping EasyAnalyticalRecords
> enabled and UseControlNumber disabled?
>
> Would appreciate any help. Thanks all!
>
> --
> Aleisha Amohia (she/her)
> Koha Developer
>
> Catalyst IT - Expert Open Source Solutions
> www.catalyst.net.nz
>
> 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  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] Sorry, your Google login failed

[Pablo Bianchi]

Did you mean AutoEmailPrimaryAddress syspref?

I'm having the same issue, but without a user already created on Koha and
GoogleOpenIDConnectAutoRegister set to Allow.
___

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

Re: [Koha] Another DBI Exception for foreign key constraint in upgrade to Koha

[Pablo Bianchi]

Thank you all for the answers!

On Sat, 3 Dec 2022 at 18:59, Katrin Fischer 
wrote:

> Do you have entries in your issues table, where the borrowernumber is
> NULL?
>

Nope. In fact, *issues* has only one row, with its integer on
borrowernumber:
issue_id: 2. *borrowernumber: 53805*. issuer_id: NULL. *itemnumber: 1581.*
date_due: 2020-10-08 23:59:00. branchcode: BC. returndate: NULL.
lastreneweddate: NULL. renewals: 0. unseen_renewals: 0. auto_renew: 0.
auto_renew_error: NULL. timestamp: 2020-10-07 15:29:52. issuedate:
2020-10-07 15:29:52. onsite_checkout: 0. note: NULL. notedate: NULL.
noteseen: NULL.
On Sun, 4 Dec 2022 at 01:00, Tomas Cohen Arazi  wrote:

> That's a data issue. Maybe an old bug let things in wrongly on the db, it
> incomplete data migration.
>
> You should do something with those checkouts with no linked patron, and
> the upgrade script will continue where it left.
>

borrowernumber (and itemnumber) are not NULL in the only row of issues
table. Also, the borrowernumber (53805) exists on borrowers table. Could be
something else?

As a last resource (I wish to avoid) I could DELETE the row. This will
always cascade any action and can't break any consistency?

JFTR, even of course upgrading to Debian 10 has nothing to do with this, I
had some trouble with Apache and Memcached and new security features of
systemd (like PrivateTmp). I had to disable them.
___

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

Re: [Koha] Another DBI Exception for foreign key constraint in upgrade to Koha

[Pablo Bianchi]

Hi Katrin,

Both bugs are resolved, but I'm having this issue while upgrading today
from 20.05 to 22.05 on a Debian 9.13:

Upgrade to 22.05.06.001 [19:37:23]: Bug 30483 - Make issues.borrowernumber
and itemnumber NOT NULL
ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Cannot change
column 'borrowernumber': used in a foreign key constraint 'issues_ibfk_1'
at /usr/share/koha/lib/C4/Installer.pm line 739

Not sure if I'm hitting another similar bug. SELECT * FROM issues WHERE
borrowernumber IS NULL OR itemnumber IS NULL; doesn't return any row. It
has only one row with ids on those columns. *reserves* table has no rows.
Maybe Bug 32240 should be backported?

Regards,
Pablo



On Mon, 10 Oct 2022 at 18:01, Katrin Fischer 
wrote:

> Hi David,
>
> please have a look at this bug and the comments there:
>
> *Bug 31673*
>  - DB
> update of bug 31086
>  fails:
> Cannot change column 'branchcode': used in a foreign key constraint
>
> Hope this helps,
>
> Katrin
>
___

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

Re: [Koha] ERRO 20.05

[Pablo Bianchi]

As Jonathan said, I fixed those errors with

INSTANCE="mylibrary" # Just set this variable
sudo chown -R ${INSTANCE}-koha:${INSTANCE}-koha /var/log/koha/$INSTANCE
___

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] Requesting feedback on changing the default behavior for loading the OPAC cart popup

[Pablo Bianchi]

*"Modals have become the today’s version of the dreaded popup window
"*
.
Shouldn't all popup windows converted to modals?
If people agree I could file a bug.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Validating OAI-PMH with openarchives.org tool

[Pablo Bianchi]

Hi all!

I tried to validate a koha data provider with
https://www.openarchives.org/Register/ValidateSite and get this two errors:

*1. FAIL baseURL supplied 'https://mysite/cgi-bin/koha/oai.pl
' does not match the baseURL in the
Identify response 'http://mysite/opac/oai.pl '.
The baseURL you enter must EXACTLY match the baseURL returned in the
Identify response. It must match in case (http://Wibble.org/
 does not match http://wibble.org/
) and include any trailing slashes etc.*
*2. FAIL Bad earliestDatestamp: The earliestDatestamp in the identify
response (2018-07-13 09:07:21) does not have the correct format for the
time part of the UTCdatetime. The overall format must be
-MM-DDThh:mm:ssZ.*

I'm using Koha 18.05.01.000 with Plack (and memcached, no warnings/errors
on *About > System Information*).

Looking at my baseURL?verb=Identify XML I see  
http://mysite/opac/oai.pl

About first error, seems bug 17785
 but I
look my code and this commit

is already applied, and should be already fixed on 18.05.

I get similar (and others) errors trying with http://validator.oaipmh.com.

Am I missing something? Using a YAML config file would be a workaround? I
wonder what other people gets when validating
 their Kohas.

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

Re: [Koha] Add pictures in notices

[Pablo Bianchi]

Reading a little bit more the source code I just've noticed that to insert
current date we should use <> instead of ​__CURRENTDATE__

.
The output will not be ISO 8601 but with the format MM/DD/ hh:mm.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Add pictures in notices

[Pablo Bianchi]

Hello,

I couldn't add some CSS style to my DISCHARGE notice, does anyone? I link
to a CSS (NoticeCSS syspref) with for example just
body { color: blue; }
h1 { color: green; }
but PDF keeps without any style, which make sense since Discharge.pm

 use PDF::FromHTML  which have the
caveat: *"This means any HTML using external or inline CSS for design and
layout, including but not limited to: images, backgrounds, colours, fonts
etc... will not be converted into the PDF."*. HTML::HTMLDoc
 doesn't look much better.
I also try some workarounds without CSS, like https://koha-community.org/files/2013/09/cropped-kohabanner3.jpg; ...
without luck.

Related: Bug 14251 - style discharge letter


It seems also impossible to add something link "At __CURRENTDATE__ Doe,
John return all his documents." like in marc modification templates.

Regards,
Pablo



Le mar. 14 mars 2017 à 13:15, Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> a écrit :

> And you can use the pref NoticeCSS to add some CSS.
>
> On Tue, 14 Mar 2017 at 13:04 Katrin  wrote:
>
> > Hi Sonia,
> >
> > I think there is no 'graphical' way of doing this, but you can use plain
> > HTML. For testing I just added this to the DISCHARGE notice template:
> >
> >  > src="https://koha-community.org/files/2013/09/cropped-kohabanner3.jpg;
> />
> >
> > The generated PDF shows the Koha logo on top - so this works. If you can
> > save the images you need somewhere accessible for Koha, this might work.
> >
> > Hope this helps,
> >
> > Katrin
> >
> >
> > On 14.03.2017 16:47, BOUIS Sonia wrote:
> > > Hello,
> > > Do you have any tip to add pictures in notices template. I've seen that
> > we could add a picture in branches.opac_info but it isn't sufficient for
> us.
> > > We want to use discharge notices but we need to insert a signature in
> it
> > to make it "official" for other universities. I would like to insert a
> > signature picture in the discharge notice template but I don't see how to
> > do..
> > >
> > > Thanks in advance,
> > > Cheers
> > >
> > > Sonia BOUIS
> > >
> > > Responsable du Service des application documentaires
> > > BIBLIOTHÈQUES UNIVERSITAIRES
> > > Bibliothèque de la Manufacture
> > > UNIVERSITÉ JEAN MOULIN LYON 3
> > > 1C AVENUE DES FRÈRES LUMIÈRE
> > > CS 78242
> > > 69372 LYON CEDEX 08
> > > ligne directe : +33 (0)4 78 78 79 03 <04%2078%2078%2079%2003>
> > http://bu.univ-lyon3.fr
> > >
> > > L'Université Jean Moulin est membre fondateur de l'Université de Lyon
> > >
> > >
> > > ___
> > > 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] How to use create_superlibrarian.pl

[Pablo Bianchi]

Also you might found useful to run
$ perldoc create_superlibrarian.pl

This work with almost all CLI Koha scripts, but sometimes with
deprecated/incomplete info.

Regards,
Pablo


Le dim. 24 juin 2018 à 12:51, Bedanta Borah  a
écrit :

> Can anyone please guide me with detailed instructions about how to use
> create_superlibrarian.pl file to create new petron with superlibrarian
> permissions?
> ___
> 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 and Omeka integration

[Pablo Bianchi]

2018-04-12 4:50 GMT-03:00 Daniel Berthereau :

> Koha and Omeka (Classic and the new version Semantic) support OAI-PMH
> ​ ​
> protocol


​They both support OAI-PMH, but both as a server (data provider), but only
Omeka also as a client (service provider).​

AFIAK is not possible the other way around. Not until Koha offer client
capabilities (bug 10662
).
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] DDoS attack on memcached

[Pablo Bianchi]

After reading about Github DDoS incident
 I found out more
about on this Cloudflare post

where
states:
> echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 -u
127.0.0.1 11211
> If you see non-empty response (like the one above), your server is
vulnerable.

And it is, but testing from outside: nmap *TARGET* -p 11211 -sU -sS
--script memcached-info
in my case (a Koha fresh install with memcached) ports are closed/filtered,
seems secure because of the firewall and this line on default
/etc/memcached.conf

# Specify which IP address to listen on. The default is to listen on all IP
addresses
# This parameter is one of the only security measures that memcached has,
so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1

So nothing to worry about, right?

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

Re: [Koha] Union Catalog using Koha

[Pablo Bianchi]

Hi Zeno,

2018-01-05 10:50 GMT-03:00 Tajoli Zeno :

> Il 05/01/2018 13:54, Mubassir Ahsan ha scritto:
>
>> Actually there are multiple universities maintain their own koha
>> installations. I am trying to connect them via Union Catalog and
>> inter-library loan.
>>
>
> to create a union catalog with different Koha installs you can:
> 1)Setup z39.50 server on every Koha
> 2)Do the union catalog with pazpar2, http://www.indexdata.com/pazpar2
> An example of pazpar2 complex conf:
> https://github.com/ssp/pazpar2-config


​Wouldn't be a third option to use OAI-PMH? Maybe with vuFind.
What are the advantages you find using the other alternatives?

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

Re: [Koha] Software error: Koha Web Installer-MARC21

[Pablo Bianchi]

2017-09-20 8:09 GMT-03:00 Dimitris Antonakis :

> You were right Chris.
> Everything works like a charm using mariadb.
>

​I had some problems installing Koha on Ubuntu 16.04. One was solved
with wizzyrea
advice  of
installing mariadb-server before koha-common. I though that was unimportant.

Other problem was: If you get a timeout, or accidentally clic a second time
on submit button you'll probably get something like
  DBIx::Class::Storage::DBI::_dbh_execute(): Duplicate entry '14-16' for
key 'PRIMARY' at /usr/share/koha/lib/Koha/SearchField.pm line 38
In those cases a I solve it with koha-remove and start again (this work
if plugin='unix_socket' beside this 
).
The timeout of course could be solved with apache2.conf directive.
The later, maybe web installer could disable submit button
(onsubmit="this.submit_button.disabled=true;") and give some feedback of
the status of the process, particularly when creating tables and filling
them with data (in my case 4 and 6 minutes each).

Also, if you use --use-memcached You'll get
  DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access
denied for user 'koha_library'@'localhost' (using password: YES)
Was hard to find the solution since koha-shell library was working fine.
The solution: Flush cache: echo flush_all > /dev/tcp/localhost/11211

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

Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[Pablo Bianchi]

2017-06-29 14:56 GMT-03:00 Tim Young :

>
> This page: https://askubuntu.com/questions/766334/cant-login-as-mysql-u
> ser-root-from-normal-user-account-in-ubuntu-16-04


If I  plugin='mysql_native_password'  (Todor answer
) I could get rid of those
[Warning] 'user' entry 'root@localhost' has both a password and an
authentication plugin specified. The password will be ignored.
when `sudo systemctl status mysql.service`. But have a side-effect:
  $ sudo koha-remove library
  Removing Koha instance library
  ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: NO)
So I move back to plugin='unix_socket' and koha-remove now works fine.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] System generated field 001 control number

[Pablo Bianchi]

Hi David,

​​On Mon, Sep 14, 2015 at 10:37 PM, David Cook 
wrote:

>
> While I agree that the 001 should be populated with a unique bibliographic
> control number, it's not the way that Koha is typically set up.


Yet for example on Koha demo of Catalyst IT Ltd. (New Zealand) we can find this
record

with biblionumber=999$c=999$d==20895 but control number 001==30908. Maybe
they take 30908 from OCLC, but that is not what we are looking for, we want
just an incremental system generated number like barcode.pl plugin builder
does for items, but for biblios, with no relation with Koha biblionumber.

In theory, it's configurable, but there are parts of Koha that expect the
> biblionumber to be in the 999$c field (e.g. MARC21slim2OPACResult.xsl).
>

I know 999 is used internally by Koha, so I don't wish to touch nothing
about biblionumber/999$c/999$d.

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

Re: [Koha] System generated field 001 control number

[Pablo Bianchi]

Hi ​Heather,

On Mon, Sep 14, 2015 at 4:42 PM, Hernandez,
​​
Heather  wrote:

> Hi, Pablo--
>
> I'm not really sure what you're asking--we use the 001 for a unique
> bibliographic control number, which for us is the OCLC record number.
>
​
We wish to have 001 as unique bibliographic control number, but our library
have nothing to do with OCLC.

Are you saying that you wish Koha could automatically generate a unique
> control number in the 001?
>

​Yes.


> Would you use this differently from the Koha record number in the 999 $c
> field?
>

​Yes. In fact we already have a control number on old records because they
come from a migration, and this numbers could overlap with biblionumber
(999$c). That's why ​​bug 9921 is not useful for us. We need on 001 a
unique record number that is not equal neither with OCLC control number nor
Koha's biblionumber.

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

[Koha] System generated field 001 control number

[Pablo Bianchi]

Hi!

As MARC manual say about control number
 *"Field 001 may be
system generated"* we wish Koha generate this number (lastUsed++), to avoid
creating manually and periodically having to run a report to remove
duplicates (from wiki
 *"There is
currently no way to enforce uniqueness in the 001, or rather uniqueness in
001 + 003."*).
We have *autoMemberNum* syspref for "next available card number",
*autoBarcode* for 952$p, barcode. but nothing for 001, no
marc21_field_001.pl vuilder plugin, only bug 9921
 about *"Make
it possible to force 001 = biblionumber"*, but that is not exactly what we
are looking for.

Being this something basic (but asked before
) I
wonder If I'm getting all wrong...

Regards,
Pablo

BTW on current manual Cataloging Guides say that 001 is "accession number
", which is
usually name to barcode.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Checkbox «Flagged» on subfield visibility framework setup

[Pablo Bianchi]

On Mon, Aug 31, 2015 at 10:47 PM, Tomas Cohen Arazi <tomasco...@gmail.com>
wrote:

> El 31/8/2015 2:38 p. m., "Pablo Bianchi" <pablo.bian...@gmail.com>
> escribió:
> > Hi!
> >
> > Even I read Koha manual
> > <
> http://translate.koha-community.org/manual/master/en/catadmin.html#marcbibframeworks
> >
> > (2.4.1.4. Edit Framework Subfields > Advanced constraint values >
> > Visibility) and bug #9894, but it isn't clear to me what a "flagged"
> > subfield means.
>
> No one knows. It's been there even before programming languages existed.
> The legend says some ancient codex relied on it to highlight the important
> facts about mortals representation of manuscripts.
>
​
I suspect I should not take your words too seriously... :P

But I suspect someone there might know what is about, been there so many
years. I read a little bit the source code but still no found answer, maybe
something to do with circulation.

If no one know I could fill a bug report to remove it.​
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Translate vs Manual sites

[Pablo Bianchi]

Trying luck on this list: ​On "Stable link to latest version of
manual" koha-docs
list nice people like Nicole, Bernardo and Larry Baerveldt help me and
create "current" symlink on manual site. But considering that
​
- current/master version of manual are hosted on translate.k-c
- those versions are far nicer than manual.k-c ones
- when you type *manual koha somthingelse* on Google always retrieve
manual.k-c, and always very old versions,
So I:
- wonder why manual.k-c exists
- suggest to put a robots.txt on both sites to keep robots out of older
versions, or at least encourage the use of *master/current* versions.

Regards!
Pabl
​o

PS: BTW, I wonder if serivces like readthedocs.org gitbook.com could make
all those tasks easyer.


On Thu, Mar 26, 2015 at 3:06 PM, Pablo Bianchi <pablo.bian...@gmail.com>
wrote:

> 2015-03-26 13:06 GMT-03:00 Bernardo Gonzalez Kriegel <bgkrie...@gmail.com>
> :
>
>> Current versions can be found at
>>
>> master
>> http://translate.koha-community.org/manual/master/en/
>> http://translate.koha-community.org/manual/master/en/html-desktop/
>>
>
> ​
> Would be really great having those much more pretty HTML versions of the
> manual on manual.koha-community.org!
> Even better would be if looked good on cellphones :P
>
>
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Checkbox «Flagged» on subfield visibility framework setup

[Pablo Bianchi]

And you are funny! :) But I was no sure if it was sarcasm, or anyone else
out there like Nicole know about this.

I filled a bug:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14772




On Wed, Sep 2, 2015 at 10:00 AM, Tomas Cohen Arazi <tomasco...@gmail.com>
wrote:

> My message pretended to be funny, and the subject of the joke was the fact
> that no one around seems to remember what that was exactly for. I think the
> best path would be to fuill a bug for its removal, so go ahead.
> If someone remembers it was a super important feature (which might be true
> for some users, remember Koha is used by more than 10K libraries around the
> world) someone will speak up an clarify on the bug.
>
> Kind regards
>
>
> 2015-09-02 9:54 GMT-03:00 Pablo Bianchi <pablo.bian...@gmail.com>:
>
>> On Mon, Aug 31, 2015 at 10:47 PM, Tomas Cohen Arazi <tomasco...@gmail.com
>> > wrote:
>>
>>> El 31/8/2015 2:38 p. m., "Pablo Bianchi" <pablo.bian...@gmail.com>
>>> escribió:
>>> > Hi!
>>> >
>>> > Even I read Koha manual
>>> > <
>>> http://translate.koha-community.org/manual/master/en/catadmin.html#marcbibframeworks
>>> >
>>> > (2.4.1.4. Edit Framework Subfields > Advanced constraint values >
>>> > Visibility) and bug #9894, but it isn't clear to me what a "flagged"
>>> > subfield means.
>>>
>>> No one knows. It's been there even before programming languages existed.
>>> The legend says some ancient codex relied on it to highlight the important
>>> facts about mortals representation of manuscripts.
>>>
>> ​
>> I suspect I should not take your words too seriously... :P
>>
>> But I suspect someone there might know what is about, been there so many
>> years. I read a little bit the source code but still no found answer, maybe
>> something to do with circulation.
>>
>> If no one know I could fill a bug report to remove it.​
>>
>>
>>
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Checkbox «Flagged» on subfield visibility framework setup

[Pablo Bianchi]

Hi!

Even I read Koha manual

(2.4.1.4. Edit Framework Subfields > Advanced constraint values >
Visibility) and bug #9894, but it isn't clear to me what a "flagged"
subfield means.

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

[Koha] Extending OPAC purchase suggestion fields

[Pablo Bianchi]

Hi!

Before using Koha we were using a local develop for purchase suggestion
requests («desdierata»). Now I'm trying to extend/add suggestion fields to
add some data we were asking in the form and Koha doesn't include,
something like what ExtendedPatronAttributes syspref does with patron
fields.
First I naively tried to add to opac-suggestions.tt
  lilabel for=newFieldExtrafield:/labelinput type=text
id=newfield name=newfield maxlength=40 //li

and  on submit:
  onsubmit=this.note.value=this.note.value+' - '+this.newfield.value;
return true;

to concatenate extended fields (yeah, dirty) but it seems Suggestions.pm do
a foreach walk over form ids:
Software error: DBIx::Class::ResultSet::create(): No such column alum on
Koha::Schema::Result::Suggestion at /usr/share/koha/lib/C4/Suggestions.pm
line 450

Because I'm trying to touch the less as possible now I'm tring a JQuery
way, but maybe someone already found an easier way...
​ ​
Maybe I should fill a bug.​

Regards,

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

Re: [Koha] loan availability of damaged items

[Pablo Bianchi]

2015-03-19 9:03 GMT-03:00 Owen Leonard oleon...@myacpl.org:

 Maybe Koha should let you define exactly which situations imply item is
 unavailable/not_for_loan.
 ...
 as a result of a search, which is misleading for the user, since it is
 still possible to check that item out.

 As far as I understand it, the goal of the display in the OPAC is to
 prevent patrons from looking for items on the shelf which are not
 available because they are damaged. This is in contrast to focusing on
 preventing the user from checking out something which is damaged.

​That's not always the case.​ On undeveloped countries is very common to
have most of the collection on closed shelf, and also allow loans of little
bit damaged books.
Anyway, there is something contradictory: damaged items are marked as
unavailable (itemavailable = 0) on item-status.inc, but in fact *they are*
available, since user can check them out (force_checkout permission have no
effect).
If for any reason librarian want to hide specific items they already have
OpacHiddenItems syspref (BTW, I never found on any Koha the
OpacHiddenItems.txt
https://github.com/fredericd/Koha/blob/master/docs/opac/OpacHiddenItems.txt
).

 I agree that it would be nice to have more
​​
fine-grained control over
 both aspects of it.

​Yes, indeed! :-)
Do you agree we have a bug (the contradiction) and a wish (​fine-grained
control) here?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] OPAC Save Record - how to remove specific tags from the export file

[Pablo Bianchi]

Hi,

2014-07-11 14:42 GMT-03:00 jbarker jbarker...@gmail.com:

 I was just wondering if anyone else has had to remove specific tags (ex
 567)
 from their OPAC export files, and if so how did you do it?


​It looks Koha don't have this feature right now. You can:
+ hide «save record» completely
http://wiki.koha-community.org/wiki/JQuery_Library#Hide_.27Save_Record.27_Box_in_OPAC
 with $(#export).remove();
+ with OpacExportOptions syspref, select exporting options that hide those
tags
+ change XSLTs internally in Koha so those tags are not translated

But (with a new function, GetFilteredOpacBiblio) signed-off bug 11592
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11592 might
solve this problem (BTW, why if a framework hide a tag/subfield on OPAC I
would let a user to see it anyway with this workaround?):

 22) And lastly, attempt to Save record in the various formats  using the 
 dropdown and clicking Go. -- The results should be filtered.

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

Re: [Koha] Problem linking authorities

[Pablo Bianchi]

Hi,

I found out what was wrong. it is a bug on Koha if the biblio framework is
not well-formed (and test don't find it). So I filled a bug report:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13776

Regards,
Pablo


2015-02-25 14:36 GMT-03:00 Pablo Bianchi pablo.bian...@gmail.com:

 Hi,

 I have a strange problem. Linking an authority works perfectly with any
 framework (like VR, DVDs) but one of them (BKS) doesn't automatically
 close the popup after linking an authority, neither complete $9 (RLIN)
 subfield. With this SQL queries* I compare side by side tags 650 (the
 problem happens with all authorites subfields, 100, 700...) of
 marc_tag_structure and subfields $9 and $a og marc_subfield_structure
 table. I update all to set them almost identical but it still have this
 strange behave. I suspect it have something to do with bug
 ​​
 #5093. Javascript console throw
 *blinddetail-biblio-search.pl:160
 http://blinddetail-biblio-search.pl:160 Uncaught TypeError: Cannot set
 property 'value' of undefined*
 choose link have last parameter empty: javascript:doauth('15583',
 'tag_650_subfield_a_127347_735090', '')
 This was working some weeks ago, so maybe is related to lastest package
 upgrades. Using Koha 3.18.4, latest Chromium and Firefox.

 Things I tried on BKS rows:
 + defaultvalue to NULL instead of empty.
 + hidden and tab field exactly same values than others frameworks,
 like VR.
 + Empty intranetuserjs syspref.
 + Removed diacritics from descriptions fields, also from biblio_framework
 table.
 + On marc_subfield_structure table, even added nonexistant table
 bibliosubject.subject to kohafield field, as added by default on sample
 builtin FWs.

 Thanks!
 Pablo

 *
 SELECT * FROM `marc_subfield_structure` WHERE tagfield=650 AND
 (tagsubfield=a OR tagsubfield=9) AND (frameworkcode=BKS OR
 frameworkcode=VR)
 SELECT * FROM `marc_tag_structure` WHERE tagfield=650


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

[Koha] Problem linking authorities

[Pablo Bianchi]

Hi,

I have a strange problem. Linking an authority works perfectly with any
framework (like VR, DVDs) but one of them (BKS) doesn't automatically
close the popup after linking an authority, neither complete $9 (RLIN)
subfield. With this SQL queries* I compare side by side tags 650 (the
problem happens with all authorites subfields, 100, 700...) of
marc_tag_structure and subfields $9 and $a og marc_subfield_structure
table. I update all to set them almost identical but it still have this
strange behave. I suspect it have something to do with bug #5093.
Javascript console throw *blinddetail-biblio-search.pl:160
http://blinddetail-biblio-search.pl:160 Uncaught TypeError: Cannot set
property 'value' of undefined*
choose link have last parameter empty: javascript:doauth('15583',
'tag_650_subfield_a_127347_735090', '')
This was working some weeks ago, so maybe is related to lastest package
upgrades. Using Koha 3.18.4, latest Chromium and Firefox.

Things I tried on BKS rows:
+ defaultvalue to NULL instead of empty.
+ hidden and tab field exactly same values than others frameworks, like
VR.
+ Empty intranetuserjs syspref.
+ Removed diacritics from descriptions fields, also from biblio_framework
table.
+ On marc_subfield_structure table, even added nonexistant table
bibliosubject.subject to kohafield field, as added by default on sample
builtin FWs.

Thanks!
Pablo

*
SELECT * FROM `marc_subfield_structure` WHERE tagfield=650 AND
(tagsubfield=a OR tagsubfield=9) AND (frameworkcode=BKS OR
frameworkcode=VR)
SELECT * FROM `marc_tag_structure` WHERE tagfield=650
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Bulk export patrons / borrowers images for batch processing

[Pablo Bianchi]

Hi,

I create my own script to do this task. Added bug report to share it :)

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

Cheers,
Pablo Bianchi

Faculty of Engineering
University of Buenos Aires
Argentina
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Http Bad request error messages

[Pablo Bianchi]

Hi!

Librarians complains about a very annoying issue (perhaps a bug): Once in a
while they get this error:

* Bad Request*
  Your browser sent a request that this server could not understand.
  Size of a request header field exceeds server limit.

This happened with Firefox (v23 to v30, either Windows and Linux clients),
from Koha 3.14 to current (for us) 3.16.
I notice Owen Leonard already had this problem (bug #10857
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10857). The
workaround is pretty simple: Just delete all browser cookies (or just Koha
ones).

I tried to reproduce the error, cleaning cookies and doing some big
searches. Even Koha documentation says they use three cookies (
http://koha-community.org/faqs/cookies-koha-use/) I ended up with this 6
cookies that all share this info:
*Host**myCatalogURL*
*Path*/
*Send for*Any type of connection
*Expires*At end of session

But different name and content (copied at the end).

Cookies seems to exceeds the facto limit of 4093 bytes per domain (
http://browsercookielimits.x64.me/) but no the RFC2109 (
http://www.ietf.org/rfc/rfc2109.txt) so this shouldn't be a problem... I
tried increasing Apache LimitRequestFieldSize directive without luck.

Regards,
Pablo

NameHc2AHbPF
Content38871 or BC=38870 or BC=38859 or BC=38863 or BC=38858 or
BC=38869 or BC=38854 or BC=38865 or BC=38868 or BC=38866 or BC=38856 or
BC=38875 or BC=38874 or BC=38853 or BC=38872 or BC=38873 or BC=38867 or
BC=38839 or BC=38880 or BC=38840 or BC=38885 or BC=38886 or BC=38882 or
BC=38886 or BC=38887 or BC=38890 or BC=38891 or BC=38879 or BC=38878 or
BC=38877 or BC=38864 or BC=38855 or BC=38852 or BC=38847 or BC=38846 or
BC=38845 or BC=38843 or BC=38841 or BC=38838 or BC=38837 or BC=38910
NameLkvXIj08
Content
%7B%22offset%22%3A1%2C%22query%22%3A%22q%253Dccl%253DBC%25253D%25252238871%252522%252520or%252520BC%25253D%25252238870%252522%252520or%252520BC%25253D%25252238859%252522%252520or%252520BC%25253D%25252238863%252522%252520or%252520BC%25253D%25252238858%252522%252520or%252520BC%25253D%25252238869%252522%252520or%252520BC%25253D%25252238854%252522%252520or%252520BC%25253D%25252238865%252522%252520or%252520BC%25253D%25252238868%252522%252520or%252520BC%25253D%25252238866%252522%252520or%252520BC%25253D%25252238856%252522%252520or%252520BC%25253D%25252238875%252522%252520or%252520BC%25253D%25252238874%252522%252520or%252520BC%25253D%25252238853%252522%252520or%252520BC%25253D%25252238872%252522%252520or%252520BC%25253D%25252238873%252522%252520or%252520BC%25253D%25252238867%252522%252520or%252520BC%25253D%25252238839%252522%252520or%252520BC%25253D%25252238880%252522%252520or%252520BC%25253D%25252238840%252522%252520or%252520BC%25253D%25252238885%252522%252520or%252520BC%25253D%25252238886
 
%252522%252520or%252520BC%25253D%25252238882%252522%252520or%252520BC%25253D%25252238886%252522%252520or%252520BC%25253D%25252238887%252522%252520or%252520BC%25253D%25252238890%252522%252520or%252520BC%25253D%25252238891%252522%252520or%252520BC%25253D%25252238879%252522%252520or%252520BC%25253D%25252238878%252522%252520or%252520BC%25253D%25252238877%252522%252520or%252520BC%25253D%25252238864%252522%252520or%252520BC%25253D%25252238855%252522%252520or%252520BC%25253D%25252238852%252522%252520or%252520BC%25253D%25252238847%252522%252520or%252520BC%25253D%25252238846%252522%252520or%252520BC%25253D%25252238845%252522%252520or%252520BC%25253D%25252238843%252522%252520or%252520BC%25253D%25252238841%252522%252520or%252520BC%25253D%25252238838%252522%252520or%252520BC%25253D%25252238837%252522%252520or%252520BC%25253D%25252238910%252522%22%2C%22limit%22%3A%22%22%2C%22sort%22%3A%22%22%2C%22pagelen%22%3A20%2C%22results%22%3A%5B560%2C695%2C1997%2C3046%2C3109%2C3399%2C4456%2C5775%2C6399%2C64
 
77%2C6736%2C7115%2C8006%2C8181%2C9287%2C11811%2C11813%2C11816%2C11817%2C11818%5D%7D
NameYRAFi4OC
Content
%7B%22offset%22%3A1%2C%22query%22%3A%22q%253Dccl%253D38871%252520or%252520BC%25253D38870%252520or%252520BC%25253D38859%252520or%252520BC%25253D38863%252520or%252520BC%25253D38858%252520or%252520BC%25253D38869%252520or%252520BC%25253D38854%252520or%252520BC%25253D38865%252520or%252520BC%25253D38868%252520or%252520BC%25253D38866%252520or%252520BC%25253D38856%252520or%252520BC%25253D38875%252520or%252520BC%25253D38874%252520or%252520BC%25253D38853%252520or%252520BC%25253D38872%252520or%252520BC%25253D38873%252520or%252520BC%25253D38867%252520or%252520BC%25253D38839%252520or%252520BC%25253D38880%252520or%252520BC%25253D38840%252520or%252520BC%25253D38885%252520or%252520BC%25253D38886%252520or%252520BC%25253D38882%252520or%252520BC%25253D38886%252520or%252520BC%25253D38887%252520or%252520BC%25253D38890%252520or%252520BC%25253D38891%252520or%252520BC%25253D38879%252520or%252520BC%25253D38878%252520or%252520BC%25253D38877%252520or%252520BC%25253D38864%252520or%252520BC%25253D38855%252520or%
 

Re: [Koha] Wipe Koha database (just auth and biblio records)

[Pablo Bianchi]

Hi Robin,

I'm aware about turning foreign keys constrains off is risky, what I was
trying to know is how risky could be, but OK, I realize that depends of
each database, and always a bad idea.

So at least we can say manual (and also bulkmarkimport.pl -d option) should
be updated (MySQL ~5.5)* adding a note about DELETE FROM biblio way not
always will work right away. This bring us to:

 In some cases the constraints will propagate the delete,
 in other cases they won't. These differences are by design.
There are good design reasons for no letting delete biblio table
propagate in all/any cases? Propagation in any case will make really simple
to update manual and bulkmarkimport.

*I'll then fill a bug report about this two issues (manual and
bulkmarkimport -d option) update.

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

Re: [Koha] Wipe Koha database (just auth and biblio records)

[Pablo Bianchi]

Hi Robin!

So you agree with me that Appendix F (Resetting the Koha Database) of
current (v3.16) manual is wrong?

2014-06-02 20:21 GMT-03:00 Robin Sheat ro...@catalyst.net.nz:

 Pablo Bianchi schreef op ma 02-06-2014 om 14:33 [-0300]:
  Am I right? This could be risky, having side effects?

 This could have nasty side-effects.

 By turning off the
 ​​
 constraint checks, you're not going to have any
 messages telling you reasons why you shouldn't do what you're doing. For
 example, circulation history, serial subscriptions, reserves, and
 anything else that links with biblios and/or items aren't going to be
 cleared. This means that you'll have entries in them pointing to things
 that don't exist.


Problems that we can avoid just with​ *DELETE FROM biblio*?


 Some better solutions might be to:
   * Do 'DELETE FROM table;' and then reset the auto numbering back
 to 1, something like 'ALTER TABLE table AUTO INCREMENT=1;'
 This'll ensure that things that should be deleted via
 constraints will be, or it won't let you do it. Also ensure that
 things that aren't constraint-linked are deleted (I think
 old_issues is one of these.)


​​Despite the autoincrement issue, the *DELETE FROM biblio* way wasn't
working for me. Now I'm not being able to reproduce the error, but I
remember was very similar than with truncate, about *foreign key constraint*
*.*

I wonder why with -d option of bulkmarcimport.pl I had similar problems
than with TRUNCATE, throw to stderr something like:

*#1701 - Cannot truncate a table referenced in a foreign key constraint
 (`koha_MyInstance`.`aqorders`, CONSTRAINT `aqorders_ibfk_2` FOREIGN KEY
 (`biblionumber`) REFERENCES `koha_MyInstance`.`biblio` (`biblionumber`))*


What we can expect just taking a look to the source code:

*if ($delete) {*
*  if ($biblios){*
*print deleting biblios\n;*
*$dbh-do(truncate biblio);*
* $dbh-do(truncate biblioitems);*
*$dbh-do(truncate items);*
*  } else {*
*print deleting authorities\n;*
*$dbh-do(truncate auth_header);*
*  }*
*   $dbh-do(truncate zebraqueue);*
*}*​

​If this way is the right one, considering constraint checks, I can't see
why we can't use it. Perhaps we can set up something differently in
my.cnf...


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

[Koha] Wipe Koha database (just auth and biblio records)

[Pablo Bianchi]

Hi all,

Once in a while I need to erase / clean / reset Koha database, and with
this I mean to remove bibliographic and authority records (leaving
systempreference intact). Some years ago it works just TRUNCATE TABLE
biblio, biblioitems, items; then with foreign key constraint the harder
DELETE FROM biblio; seems to do the job. cleaning all other tables in
cascade.

But now (with Koha v3.16) I just want to say that *Appendix F. Resetting
the Koha Database
http://manual.koha-community.org/3.16/en/resetkohadb.html* might be not
exactly right, but with this trick
http://stackoverflow.com/questions/5452760/truncate-foreign-key-constrained-table
(disable foreign key constraint checks) seems to work:








*SET FOREIGN_KEY_CHECKS=0;TRUNCATE TABLE biblio;TRUNCATE TABLE
biblioitems;TRUNCATE TABLE items;TRUNCATE TABLE auth_header;TRUNCATE TABLE
sessions; TRUNCATE TABLE zebraqueue;SET FOREIGN_KEY_CHECKS=1;*

And of course then: *koha-rebuild-zebra --verbose --full  $(koha-list)*

Am I right? This could be risky, having side effects?

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

Re: [Koha] [Koha-devel] Kohacon 2014 in Córdoba, Argentina

[Pablo Bianchi]

2013/10/7 Tomas Cohen Arazi tomasco...@gmail.com

 On Mon, Oct 7, 2013 at 7:48 AM, Mirko 5...@gmx.de wrote:

 Hi everybody,

 Kohacon 2014 will take place in Córdoba, Argentina! Congratulations!


 Yay!

 Thanks fellows for trusting us for such an important event. We will put
 all our efforts to make KohaCon14 unforgetable :-D


Congratulations! I'll be very proud and happy to have you all in my
country! *:)*

Pablo Bianchi
Buenos Aires, Argentina
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Building authority records after data migration

[Pablo Bianchi]

2013/6/18 Galen Charlton g...@esilibrary.com

 On Tue, Jun 18, 2013 at 12:14 AM, Iming Chan imingc...@yahoo.com.au
 wrote:
  Recently, I have successfully migrated all bibliographic records into
 Koha
  3.12.  I would like to find out how to build up authority records using
 bib.
  records that are in Koha?  There doesn't seem to be any instruction on
 this
  that will help newbie (like myself) to achieve this.
 My general recommendation for this sort of situation is to *not* build
 authority records based on the bib records.  Why?  First,
 machine-created authority records will end up authorizing any typos
 and other errors that may exist in your bib headings.  Second, much of
 the value of authority records, particularly for Koha's headings
 search feature, comes from cross-references, which can't be
 machine-generated.  Consequently, I recommend that you consider
 downloading authority records from sources such as LC and NLA or using
 an authority control service.

 That said, if you want to proceed, you can make Koha create authority
 records by first turning on both the AutoCreateAuthorities and
 BiblioAddsAuthorities system preferences, then saving each bib record
 individually (and slowly, so that Koha stays on top of indexing the
 new authority records).

 At the moment, there isn't an easy, reliable way to do so as a batch
 operation; while running the command line link_bibs_to_authorities.pl
 script will create authority records automatically if the two system
 preferences I mentioned are enabled, doing it in one fell swoop will
 creating duplicate authority records.  Why?  Because newly-created
 authority aren't indexed instantaneously, so a new one may exist in
 the database but not be findable by the linker script yet.

 To work around that, you could write a script that did the equivalent of

 link_bibs_to_authorities.pl  --bib-limit 'biblionumber = 1'
 misc/migration_tools/rebuild_zebra.pl -b -a -z
 link_bibs_to_authorities.pl  --bib-limit 'biblionumber = 2'
 misc/migration_tools/rebuild_zebra.pl -b -a -z
 link_bibs_to_authorities.pl  --bib-limit 'biblionumber = 3'
 misc/migration_tools/rebuild_zebra.pl -b -a -z
 ...
 link_bibs_to_authorities.pl  --bib-limit 'biblionumber = '
 misc/migration_tools/rebuild_zebra.pl -b -a -z


I add a line (around 96) to execute rebuild_zebra.pl just before processing
each record:
*[...]
while ( my ($biblionumber) = $sth-fetchrow_array() ) {
system(/usr/bin/perl /usr/share/koha/bin/migration_tools/
rebuild_zebra.pl -b -a -z);
$num_bibs_processed++;
process_bib( $linker, $biblionumber )
[...]*

In my case it took about 3 minutes for each 100 records.
Note *migration_tools*/ is under bin because is a standard package
installation instead of a git one.

But, even this *should *work, it seems it doesn't, I wonder why... Paths
are correct.
Are any other workaround to generate authorities from biblio records? Or a
script to deduplicate authorities...

Regards!
Pablo Bianchi
Bs As, Argentina
​
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha