Re: [Koha] How To Add OCLC in Koha Z39.50 Server.

[Mark Alexander]

I'm not an expert on this, but it appears that zcat.oclc.org requires
you to provide your OCLC user name and password, as mentioned in the
message mentioned previously:

https://www.mail-archive.com/koha@lists.katipo.co.nz/msg25554.html

Here is what happened when I tried to connect using yaz-client without 
username/password:

% yaz-client zcat.oclc.org:210/OLUCWorldCat
Connecting...OK.
Sent initrequest.
Connection rejected by v3 target.
UserInformationfield:
{
  OID: 1 2 840 10003 10 1000 17 1
  {
ANY (len=29)
  }
}
OCLC UserInformation:
{
  failReason TRUE
  text 'Invalid Autho/password'
}
Options: search present delSet triggerResourceCtrl scan sort extendedServices 
namedResultSets
Elapsed: 0.193017

-- 
Fundamentally, there may be no basis for anything. --Ashleigh Brilliant
___

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

[Koha] Multiple simultaneous connections to SIP2

[Mark Alexander]

We have a content provider, Lyrasis, attempting to use a SIP2 connection
to our Koha server to do user authentication.  Lyrasis claims that our SIP2
server is not able to handle multiple simultaneous connections, but
but I could not reproduce the problem with my own test scripts.  I was
wondering if anybody else had run into this problem.

Here's what they're saying about the problem:

"So long as we don't have more than one active connection, when we send
the login message with or without the `rpl` location code and with or
without error detection, we get the same successful login response
message (94) with `login_ok` set to `1` (success). Subsequent status
(99), patron status (23), and patron information (63) request messages
also return the expected results. 

"But if we attempt to open more than one simultaneous connection, all
messages hang and timeout.

"Would it be possible to allow our service to establish more than once
connection? Our service runs on multiple servers, each supporting
multiple threads, so it is likely that we would, from time to time,
need to make multiple simultaneous connections to your SIP2 service."

-- 
I think I'll just sit here and wait
until life gets easier. --Ashleigh Brilliant
___

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

Re: [Koha] Problem with the Koha Upgradation

[Mark Alexander]

Excerpts from Shiva Kumara's message of 2022-03-07 12:57:51 +0530:
> {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate column name
> 'letternumber'  at /usr/share/perl5/DBIx/Class/Schema.pm line 1118.

I ran into this problem recently when I upgraded Koha 3.16 to the latest stable 
Koha.
I fixed this by commenting out the following statement in updatedatabase.pl and 
restarting
koha-upgrade-schema:

$dbh->do("ALTER TABLE overduerules_transport_types ADD COLUMN letternumber 
INT(1) NOT NULL DEFAULT 1 AFTER id");

You will probably run into another error:

{UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Can't DROP INDEX `isbn`; 
check that it exists  at /usr/share/perl5/DBIx/Class/Schema.pm line 1118.

I fixed this by commenting out these two lines in updatedatabase.pl:

$dbh->do( "ALTER TABLE biblioitems DROP INDEX isbn" );
$dbh->do( "ALTER TABLE biblioitems DROP INDEX issn" );

-- 
One possible reason why things aren't going according to plan
is that there never was a plan. --Ashleigh Brilliant
___

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

Re: [Koha] koha-z3950-responder and item status

[Mark Alexander]

Excerpts from Mark Alexander's message of 2022-02-13 12:08:33 -0500:
> Now it seems that in recent Koha, you're supposed to start the Z3950 responder
> with /usr/sbin/koha-z3950-responder.  But this script doesn't seem to
> offer any equivalent to --add-item-status=k.

I was in a hurry, so I patched koha-z3950-responder as follows.
I don't like patching Koha installed from packages, but I don't see
any other way to do this.

*** koha-z3950-responder.orig   2022-02-13 17:49:11.905782437 +
--- koha-z3950-responder2022-02-13 17:49:32.907771774 +
***
*** 105,110 
--- 105,111 
  
  Z3950OPTS="-c ${CONFIGDIR} \
 -u ${instance_user} \
+--add-item-status=k \
 -p ${PIDFILE} ${daemonize} ${logging}"
  
  if ! is_z3950_running ${instancename}; then

-- 
Inform all the troops that communications have
completely broken down. --Ashleigh Brilliant
___

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

[Koha] koha-z3950-responder and item status

[Mark Alexander]

I've been fighting with the Z3950 responder for several years now.  In
particular, I want get it to respond with a 952$k field that gives an
item status as "Available" or "Checked out".  In the past (prior to
19.11) I've had to install my own version of ByWater's Z3950
responder, and invoked it with something like this:

  /usr/share/koha/bin/z3950_responder.pl --add-item-status=k tcp:@:

Now it seems that in recent Koha, you're supposed to start the Z3950 responder
with /usr/sbin/koha-z3950-responder.  But this script doesn't seem to
offer any equivalent to --add-item-status=k.  So when I use yaz-client
to query an item, I see that 952$k is indeed missing:

  952$0 0 $1 0 $2 ddc $4 0 $6 F_HEG $7 0 $8 FICTIONA $9 910 $a VSNY $b VSNY 
$c FIC $d 2009-03-21 $l 0 $o F HEG $p 3VSNY1973A $r 2020-04-09 $t 1 $w 
2009-03-21 $y BK $x FSC@aR@c19990908

I've looked in the files in /etc/koha/sites/INSTANCE/z3950/config.xml,
and don't see anything relevant.  How do I get 952$k to appear?

-- 
I wish I had done some of the hard things
when they were easier to do. --Ashleigh Brilliant
___

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

Re: [Koha] Importing encrypted patron passwords

[Mark Alexander]

I've managed to get the database upgrade to succeed, but it failed at four 
different
places:

* 3.19.00.037
* 3.21.00.027
* 3.23.00.041
* 16.06.00.050

The fixes involved manual updates to the database, or commenting out lines
in updatedatabase.pl, or both.

Thanks to all those who offered help.

-- 
By doing just a little every day, I can gradually let
the task completely overwhelm me. --Ashleigh Brilliant
___

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

Re: [Koha] Importing encrypted patron passwords

[Mark Alexander]

Thanks for the help.  The koha-upgrade-schema step went well until this:

Upgrade to 3.19.00.037 done (Bug 13810: Change collate for tagsubfield 
(utf8_bin))
{UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Incorrect datetime value: 
'-00-00 00:00:00' for column `koha_cfl`.`virtualshelves`.`created_on` at 
row 1  at /usr/share/perl5/DBIx/Class/Schema.pm line 1118.
DBIx::Class::Schema::throw_exception(Koha::Schema=HASH(0x55f9a91d9528), 
"DBI Exception: DBD::mysql::db do failed: Incorrect datetime v"...) called at 
/usr/share/perl5/DBIx/Class/Storage.pm line 113

DBIx::Class::Storage::throw_exception(DBIx::Class::Storage::DBI::mysql=HASH(0x55f9ae477430),
 "DBI Exception: DBD::mysql::db do failed: Incorrect datetime v"...) called at 
/usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1501
DBIx::Class::Storage::DBI::__ANON__("DBD::mysql::db do failed: 
Incorrect datetime value: '-00-"..., DBI::db=HASH(0x55f9ae93d640), undef) 
called at 
/usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 
10391

Here are the relevant lines from updatedatabase.pl:

$DBversion = "3.19.00.038";
if ( CheckVersion($DBversion) ) {
$dbh->do(q|
ALTER TABLE virtualshelves
ADD COLUMN created_on DATETIME NOT NULL AFTER lastmodified
|);

I tried running this ALTER statement manually, and it succeeded.  So the 
problem does
not seem to be MariaDB.

-- 
If you're careful enough, nothing bad or good
will ever happen to you. --Ashleigh Brilliant
___

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

Re: [Koha] Importing encrypted patron passwords

[Mark Alexander]

Excerpts from Alvaro Cornejo's message of 2022-02-05 19:40:08 -0500:
> I'll however suggest you do the backup load/upgrade before configuring the
> server since some of the data uses DB indexes to be identified.

Let me see if I understand this.  Is this the order of steps you're 
recommending?

0. install Debian 10 on new server
1. apt-get install koha-common
2. copy database from the old server (mysqldump args >dump.sql)
   and load it on new server (mysql args http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Importing encrypted patron passwords

[Mark Alexander]

I'm in the process of upgrading a library's Debian 7/Koha 3.16 setup.
This installation is so old that an in-place upgrade can't be done.
My plan is to first create a test VM with Debian 10 and the latest
stable koha-common.  Then after manually setting up various admin
things (library, item types, ccode, loc, patron types), I'll import
the catalog and the patron list.  Finally, I'll move the resulting
database to the real (live) server.

The snag here is the patron passwords.  I'll use a report from the SQL
library to export the patron list from the old installation, but the
passwords will be encrypted.  My understanding is that when importing
the patron list, the passwords must be unencrypted.  So I'll need to
remove the password column from the CSV file, and as a result,
every patron password will have to be reset manually.

Is there any workaround for this?  I would just like to move the
encrypted passwords from the old installation to the new one.  I am
comfortable doing some hand-crafted SQL updates to accomplish this.
But before I make the attempt, is there any reason why this wouldn't
work or why it's a bad idea?

-- 
Single-handedly, I have fought my way
into this hopeless mess. --Ashleigh Brilliant
___

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

Re: [Koha] software error while batch editing records

[Mark Alexander]

Excerpts from Mathieu Saby's message of 2022-01-02 12:52:34 +0100:
> Template process failed: undef error - unexpected end of string while
> parsing JSON string, at character offset 65535 (before "(end of
> string)") at .../Koha/BackgroundJob.pm line 182.

That 65535 (0x in hex) is pretty suspicious.  Sounds like a buffer
size limit/overrun bug, but I have not looked at the code.

-- 
My object is to save the world, while still leading
a pleasant life. --Ashleigh Brilliant
___

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

Re: [Koha] Migrate checkouts with koc file

[Mark Alexander]

Excerpts from Bales (US), Tasha R's message of 2021-12-10 17:46:06 +:
> In short, is there a way to make my own .koc file from scratch by supplying 
> the extension, necessary columns, and required header?  Thanks for your time,

Yes, you can do this.  I did this as part of a migration from Mandarin to Koha.
I wrote a Ruby script that parsed a Mandarin report for "loan list by patrons",
and massaged it into a .koc file.  This probably won't help, but just in case,
that script and a few others I had to write to do the migration are here:

https://gitlab.com/bloovis/marc

-- 
Surely I deserve some kind of recognition for all
the bad things I haven't done. --Ashleigh Brilliant
___

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

Re: [Koha] Reason to define Koha item type in 942

[Mark Alexander]

Excerpts from Bales (US), Tasha R's message of 2021-10-14 19:13:14 +:
> I recall reading (in the Koha manual?) the explanation for why it is 
> advantageous to define Koha item type in the bib 942 field.  I believe it has 
> to do with exporting records, or the scope of records that is included when 
> doing some type of report?  I'm trying to locate that information again, but 
> can't find it for the life of me.

I can't find the information right now, though I know I've seen it somewhere.

My understanding is when importing a MARC record, 942$c is treated as the
item type in the bibliographic record, and 952$y is the item type
for the item record (assuming a 952 holding field was present).

I have also observed that when you create a new item record from an
existing bib record, 942$c gets copied into the new item's type.  So
it's helpful to make sure that the item type in the bib record was set
correctly when it was created (or imported).

This wiki page talks about 952, but not 942:

https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx)

I'm sure someone more knowledgeable can correct this if I'm wrong.

-- 
I am unconditionally guaranteed to be
full of defects. --Ashleigh Brilliant
___

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

Re: [Koha] Upgrade OS - Ubuntu 18.04 to 20.04

[Mark Alexander]

Excerpts from Alvaro Cornejo's message of 2021-06-25 18:25:51 -0500:
> We also use a VPS provider (Linode) for the koha hosting.
> 
> What we do when migrating to a major version is to create a new VPS,
> install everything from scratch, move the DB from the old system to the new
> one, do the DB conversion and test that everything goes as expected.

I also use Linode, but I have done a similar upgrade without creating a
second VPS and migrating the database.  Perhaps that's living a bit
dangerously, but it worked for me.  I used Linode's backup feature to
give me an escape route if something went wrong.  Briefly, here's what
I did:

I shutdown the machine completely, and created a manual backup of the
entire machine.  After rebooting, I did the upgrade from Debian 8 to
Debian 9.  This was done using various apt commands.  I recall that I
had to use Linode's out-of-band ssh service instead of normal ssh at
one point, because the upgrade brought down Debian's network service
briefly.

After the OS upgrade, I made another manual backup of the entire machine.
I also made a backup of the Koha database and configuration, and copied those
files to my own laptop.  Finally, I did the Koha upgrade using the usual
'apt install koha-common'.

-- 
Let's organize this thing and take all
the fun out of it. --Ashleigh Brilliant
___

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

Re: [Koha] Barcode's continued

[Mark Alexander]

Excerpts from library's message of 2021-02-18 10:22:59 -0600:
> I tried the perl that Jonathan sent but the Internet did not give good  
> advise on how to run the perl. Here is what I typed:

When I compare Jonathon's script with yours, I see some typos in yours:

holingbranch =>$branchcode,

This should be holdingbranch.

barccode=>"barcode_'.$biblio->biblionumber,

The single quote ' should be a double quote ".

)-store;

There should be a > after the -, i.e. ->

To run this script, first use this command to set up the proper environment:

   koha-shell INSTANCE

where INSTANCE is your Koha instance name (it appears to be ppa in your case).

Then you can run the script using this:

  perl scriptname.pl

-- 
To any truly impartial person, it would be obvious
that I'm always right. --Ashleigh Brilliant
___

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

Re: [Koha] Koha 20.11 Plugins

[Mark Alexander]

Excerpts from Nelson Mwirigi's message of 2020-12-17 09:51:27 +0300:
> Thank you. I had installed Koha 19.05. So when I installed koha 20.11 and
> restored backup from Koha 19.05, I am not able to see the plugin option
> under  "Tools" so I cannot even add plugin.

This confused me for a couple of weeks until a helpful developer
pointed out to me that the link for adding plugins was removed from
the Tools home page and moved to the Administration home page: there's
a "Manage plugins" link on the left side at the bottom.

-- 
I am unconditionally guaranteed to be
full of defects. --Ashleigh Brilliant
___

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

Re: [Koha] Autodelete backups older than 5days

[Mark Alexander]

Excerpts from muiru james's message of 2020-12-05 13:10:56 +0300:
> I have my Koha instance backing up automatically to dropbox through a bash
> script. I need to automatically delete archives older than 5 days. How do I
> do it?

If you're using rsync to send the backups from your Koha server to
dropbox, you can use the --delete option.  That will delete files on
dropbox that are not present on the Koha server.  I don't use use dropbox,
but I do something like this to copy backups to my home machine:

rsync -av --delete r...@koha.example.com:/var/spool/koha/INSTANCENAME/ 
koha-backups

-- 
Let's organize this thing and take all
the fun out of it. --Ashleigh Brilliant
___

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

Re: [Koha] Plugin Administration and Installation

[Mark Alexander]

Excerpts from Tomas Cohen Arazi's message of 2020-11-24 17:24:21 -0300:
> Did you restart memcached as well? The changes to the koha-conf.xml file
> are cached.

I just tried that, and it had no effect.

This problem occurred before I made any attempts to change
koha-conf.xml, which was already set up correctly (as far as I can
tell) by koha-testing-docker.  So restarting all of these services
should not have been necessary in any case.


-- 
My life would be very empty if I had
nothing to regret. --Ashleigh Brilliant
___

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

Re: [Koha] Plugin Administration and Installation

[Mark Alexander]

Excerpts from mik's message of 2020-11-20 11:36:44 +0100:
> You will also have to activate Koha system preference "UseKohaPlugins".
> 
> Then you'll find the plugin option in Koha menu "Tools".
> 
> This is all described in the fine Koha manual:
> 
> * https://koha-community.org/manual/20.05/en/html/plugins.html

The manual is out of date.  UseKohaPlugins was removed
for 20.05.  See bug 20415:

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

Coincidentally, I'm having the same problem that is being discussed
here, but only on koha-testing-docker; a stock installation of 20.05
on Debian is working fine.  I can see that pluginsdir and
enable_plugins are set correctly in koha-conf.xml, and I've logged in
as a user with superlibrarian privileges.  But I don't see "Tool plugins"
under "Additional tools" in the Tools page.  I've tried restarting
plack, apache2, and koha-common, to no avail.

-- 
If we all work together, we can totally
disrupt the system. --Ashleigh Brilliant
___

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

Re: [Koha] Koha and Kanopy integration via SIP2

[Mark Alexander]

Excerpts from Steve Nickerson's message of 2020-11-04 12:16:45 -0500:
> Does anyone have experience getting Koha "connected" to Kanopy via SIP2?

I have done this, and it was not a trivial task.  Our library decided
that the use of Kanopy should be enabled or disabled for each patron,
and not globally enabled.  This complicated things a lot.  I had to
add a KANOPY_OK patron attribute, write a plugin, and patch the SIP2
server.  I wrote some notes about the process, which I've included
below and anonymized.  The notes are a bit rough, so if something
doesn't make sense, please ask for clarification.  Note also that I am
using Koha 19.11.06 and haven't tested this with later versions of
Koha.

I've put the code for the plugin here:

https://gitlab.com/bloovis/marc/-/blob/master/koha-plugins/Koha/Plugin/Com/Bloovis/Sip2patron.pm

The patch for the SIP2 server is here:

https://gitlab.com/bloovis/marc/-/blob/master/SIP-plugin.patch

The plugin and patch cause the SIP2 server to check that the KANOPY_OK
patron attribute is set for the patron being queried by Kanopy.

(In the following, replace 'lib' and 'LIB' with your actual Koha library 
instance name,
lower- or upper-case as appropriate.)

First, enable the ExtendedPatronAttributes preference.  Then in
Administration / Patron Attribute Types, create a new attribute type
called KANOPY_OK.  This has an authorized value category of YES_NO,
and will be used to indicate that the patron is allowed to use Kanopy.

On the Koha server, add a new user called "kanopy" using this command as root:

adduser kanopy

Respond to the password prompt by entering a hard-to-guess password, preferably
one generated randomly.

In the following examples, replace '**password**' with the password you just
assigned to the kanopy user.

In the Koha staff client, add a patron called "kanopy" with a hard-to-guess 
password.
For simplicity, the password can be the same as the one you assigned to the 
user above.
Give this patron "circulation" permissions.

Log into the Koha server as root using ssh.  Then run:

   koha-enable-sip rpl

Edit /etc/koha/sites/rpl/SIPconfig.xml.

In the "listeners" section, remove the IP address restriction in
the port setting for the 6001/tcp service, so that it looks like this:

  port="6001/tcp"

The "accounts" section should have one entry:



Make the password match the patron's password that was set above.

The "institutions" section should have one entry:


  


Start the SIP server:

koha-start-sip lib

To test SIP2, Use this command:

telnet localhost 6001

Enter the login message:

9300CNkanopy|CO**password**|CPLIB|

where '**password**' is the password of the kanopy patron.
This should return the response:

941

Then check the kanopy patron using this message:

6300020180906174600Y AOLIB|AAkanopy|AD**password**

This should return the following response (line split for clarity):

64  00020180907
074824AOLIB|AALIBKANOPY|
AE Kanopy|BLY|CQY|CC5|ben...@example.com|BF555-1212|PCS|PIY|AFGreetings 
from Koha. |

Enter a blank line to exit.

The SIP2 protocol is not encrypted, so the client (Kanopy's server)
must set up an ssh tunnel that encrypts the SIP2 traffic.  To verify
that this will work, run this from another machine:

ssh -f -N -L 9876:koha.example.com:6001 kan...@koha.example.com

This sets up an ssh tunnel from port 9876 on the local (client) machine
to port 6001 on the Koha server (koha.example.com).
After you enter the password for kanopy, ssh will go into the background.
Then you can use this to test the tunnel:

telnet localhost 9876

Then enter the SIP2 messages as described in the previous section.

Finally, you will need to submit a Kanopy Library Authentication Integration
form to Kanopy, telling it about how it can access your SIP2 server.
This information will include:

* your Koha server name, IP address, and SIP2 port (6001 in the example above)
* the name and password of a valid patron account for testing (I created
  a special patron solely for this purpose)
* the credentials for the SSH tunnel (kanopy:**password**@koha.example.com:22
  in the example above)

-- 
I am currently going through a difficult transition period
called "Life". --Ashleigh Brilliant
___

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

Re: [Koha] SIP2 and telnet.

[Mark Alexander]

Excerpts from sam aikins's message of 2020-10-18 03:09:06 +0800:
> Has anyone been able to telnet to SIP2 successfully.

It works for me, and I also wrote a couple of Ruby scripts that use telnet
to test the SIP2 connection.  Here's one of those with the library,
username, and password anonymized.

#!/usr/bin/env ruby
require 'ruby_expect'
host = ARGV[0] || 'localhost'
$logger = ::Logger.new($stdout)
$logger.level = ::Logger::DEBUG # was WARN
exp = RubyExpect::Expect.spawn("telnet #{host} 6001", {logger: $logger})
exp.procedure do
  # Expect each of the following
  each do
expect /Trying .*\.\.\./ do
end

expect /Connected to #{host}/ do
end

cmd93 = '9300CNuser|COpassword|CLIB|'
expect /Escape character is/ do
  send cmd93
end

# telnet echoes back everything we send, so we have to expect that.
expect cmd93 do
end

cmd23 = '2300120060101084235AOLIB|AAuser|ACsip_01|ADpassword|'
expect /941/ do
  send cmd23
end

# telnet echoes back everything we send, so we have to expect that.
expect cmd23 do
end

expect /24.*USER\|AAR9901\|BLY\|CQY\|AFGreetings from Koha.*\|AOLIB\|/ do
  send "\r"
end

expect /Connection closed by foreign host/ do
end
  end
end

-- 
According to all the latest reports, there was no truth
in any of the earlier reports. --Ashleigh Brilliant
___

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

Re: [Koha] Holds and quarantine

[Mark Alexander]

Excerpts from mik's message of 2020-09-16 19:27:46 +0200:
> Maybe the section "How will this help libraries?" of the following 
> how-to will give you more ideas:
> 
> https://bywatersolutions.com/education/new-system-preference-for-trapping-holds

Excellent, thank you!  I missed this, and I believe it is
the correct solution for us.
___

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

[Koha] Holds and quarantine

[Mark Alexander]

I've tried to search my Koha mailing list archives, and studied the
19.05 manual for a solution to the following problem, but I'm either
overlooking something or the problem hasn't been discussed.

Our little library has a pandemic protocol where books that are returned (in
a drop box) are checked in twice a week, then put on a special quarantine table.
On Sunday a volunteer comes in and sanitizes the books.  Then they can be
checked out again.

The problem has to do with holds.  When a book with a hold is checked in,
the librarian has to respond to Koha's popup in one of two ways: press 
"Confirm",
or press "Ignore":

1. If the librarian presses "Confirm", then the patron will eventually
notice when they log into to their account that the book is ready
for pickup, when in fact it is on the quarantine table and is NOT
ready.

2. If the librian presses "Ignore", then the patron won't get notified
that their book is ready for pickup.  Instead, their hold is
still pending and the book is seen as available in the catalog.

Either choice isn't quite right.  What we'd like to have happen is for
the patron somehow to be informed that their book is ready for pickup
not when it's checked in, but AFTER it's gone through the quarantine
process, which takes an unpredictable amount of time.

I don't see how the CART shelving location functionality and cron job
can deal with both holds and unpredictable quarantine times.

Thanks in advance for any ideas!
___

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

Re: [Koha] SQL edit for Non-circulating items report

[Mark Alexander]

Excerpts from David Sale's message of 2020-07-31 19:12:13 +:
> However, adding "b.isbn" to the SELECT list (as with "b.title", "b.author", 
> etc.) breaks the report and renders it non-functional.

You might find this page useful, since it does provide some isbn examples:

https://wiki.koha-community.org/wiki/SQL_Reports_Library

The problem with your query is that isbn is not a field in the biblios
table; it is in the biblioitems table.  You'll need to join that table
to the query, perhaps like the one below.

SELECT bi.isbn, i.itemcallnumber, b.biblionumber, b.title, b.author, 
b.copyrightdate,
   i.barcode, i.datelastseen, i.issues AS totalcheckouts,
   i.dateaccessioned
FROM items i
LEFT JOIN issues
USING (itemnumber)
LEFT JOIN biblio b
USING (biblionumber)
LEFT JOIN biblioitems bi
USING (biblionumber)
WHERE homebranch = <> AND location = <> AND i.withdrawn=0 AND
i.itemlost=0 AND i.damaged=0 AND i.itemnumber NOT IN (SELECT issues.itemnumber 
FROM issues)
  AND  YEAR(NOW())-YEAR(i.datelastseen) > <>
ORDER BY i.itemcallnumber ASC
___

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

Re: [Koha] General Query

[Mark Alexander]

Excerpts from Sanjay Uchcharia's message of 2020-07-19 19:56:45 +0530:
> How would I find/see my Koha z39.50 target?

This might help:

https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server

and:

https://wiki.koha-community.org/wiki/Troubleshooting_Koha_as_a_Z39.50_server
___

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

Re: [Koha] Error staging MARC records

[Mark Alexander]

It turned out that the configuration issue was a missing tmp_path
entry in koha-conf.xml.  There was some information about
this in bugzilla 20428; it seems the Debian 9 has issues with /tmp.

Here are the relevant entries in my fixed koha-conf.xml:

 /var/lib/koha/rpl/uploads
 /var/lib/koha/rpl/tmp

After adding tmp_path I discovered that it wasn't sufficient to get
Koha to recognize the new tmp_path by doing the following:

  systemctl stop koha-common
  systemctl start koha-common

I had to reboot the machine for the change to be effective.  I suspect
this is a plack-related issue, and that it might have been sufficient
to restart plack.
___

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

[Koha] Error staging MARC records

[Mark Alexander]

I recently upgraded our Koha from 19.05 to 19.11.06, and upgraded the underlying
OS from Debian 8 to Debian 9.

I'm now getting an error when I try to stage MARC records for import.
The upload seems to work correctly, and I see the uploaded file in
/tmp/koha_rpl_upload/, but Koha says the file doesn't exist when I press the
"Stage for import" button.

Here are the last two lines in intranet-error.log; I've inserted
carriage returns for readability and anonymized the library name:

[Fri Jun 05 06:07:49.132250 2020] [cgi:error] [pid 2025] [client 
104.219.99.61:42282] AH01215: [Fri Jun  5 06:07:49 2020]
  stage-marc-import.pl: Use of uninitialized value in subroutine entry at 
/usr/share/koha/lib/Koha/Plugins/Base.pm line 182.:
  /usr/share/koha/intranet/cgi-bin/tools/stage-marc-import.pl, referer: 
https://koha.OURLIBRARY.com:82/cgi-bin/koha/tools/manage-marc-import.pl
[Fri Jun 05 06:08:06.283046 2020] [cgi:error] [pid 2062] [client 
104.219.99.61:42286] AH01215: [Fri Jun  5 06:08:06 2020]
  stage-marc-import.pl: 
/usr/share/koha/intranet/cgi-bin/tools/stage-marc-import.pl:
  cannot open input file 
/tmp/koha_rpl_upload/1371f85fdaf426b84bd9a782ce82bccf_set31.marc:
  No such file or directory: 
/usr/share/koha/intranet/cgi-bin/tools/stage-marc-import.pl,
  referer: 
https://koha.OURLIBRARY.com:82/cgi-bin/koha/tools/stage-marc-import.pl

When I log in with ssh, I can see the file mentioned in the error message:

% ls -laF /tmp/koha_rpl_upload/1371f85fdaf426b84bd9a782ce82bccf_set31.marc
-rw-r--r-- 1 rpl-koha rpl-koha 3953 Jun  5 06:07 
/tmp/koha_rpl_upload/1371f85fdaf426b84bd9a782ce82bccf_set31.marc

I see that Elaine Bradtke reported this same error back on Aug 19, but said
that the problem was due to a configuration issue that she did not
describe.  I'd like to know what sort of configuration issues could
cause this error.

Just in case, I've disabled all plugins, and the problem persists.

For completeness, here is what the About page says:

Koha version:   19.11.06.000
OS version ('uname -a'):Linux koha 5.6.1-x86_64-linode134 #1 SMP 
PREEMPT Wed Apr 1 22:25:48 UTC 2020 x86_64
Perl interpreter:   /usr/bin/perl
Perl version:   5.024001
Perl @INC:  /usr/share/koha/lib
/usr/share/koha/installer
/usr/share/koha/lib/installer
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.24.1
/usr/local/share/perl/5.24.1
/usr/lib/x86_64-linux-gnu/perl5/5.24
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.24
/usr/share/perl/5.24
/usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base
/var/lib/koha/rpl/plugins
/var/lib/koha/rpl/plugins
MySQL version:  mysql Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu 
(x86_64) using readline 5.2
Apache version: Server version: Apache/2.4.25 (Debian)
PSGI:   Plack (deployment)
Memcached:  Servers: 127.0.0.1:11211 | Namespace: koha_rpl | Status: 
running. | Config read from: koha-conf.xml
Zebra version:  Zebra 2.0.59 (C) 1994-2014, Index Data Zebra is free software, 
covered by the GNU General Public License, and you are welcome to change it 
and/or distribute copies of it under certain conditions. SHA1 ID: 
c00bfddbf0f3608340d61298acc61dafb167f9b2 Using ICU
Date and time:  06/05/2020 06:10
Time zone:  Used: America/New_York | Config: Undefined | Environment (TZ): 
Undefined
___

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

Re: [Koha] Report help needed

[Mark Alexander]

Excerpts from Michael Sutherland's message of 2020-05-27 16:59:50 -0400:
> CASE SUBSTR(metadata,282,2)

I tried this myself, and it does seem to work.  But I worry that
the 282 value might not be correct in the future, should the XML
format of the metadata change even slightly.  In particular,
the XML header has a field called xsi:schemaLocation that contains
a URL that might change someday.  I could very wrong about this,
though; perhaps the format really is stable.

This does the same job and seems less obscure (to me, anyway):

  substring(ExtractValue(metadata, '//leader'), 7, 2)

But perhaps it's not as fast?  I'm not a MySQL expert by any means.
___

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

Re: [Koha] Barcode as a link report

[Mark Alexander]

Excerpts from muirunyeri's message of 2020-05-19 11:10:33 +0300:
> However if anybody would help me understand why I get an error (biblionumber 
> is ambiguous) after adding any field from biblio table I'd be really 
> grateful. This after correctly adding a left join for the biblios table using 
> biblionumber on itemnumber in items.

It would help if you could post your entire query.  But my guess is
that the ambiguity is the result of joining two tables that have
fields with the same name.  The items and biblio tables both have a
field called biblionumber.  So in your query, you have to fix the
ambiguity by using the table name as a prefix: e.g.,
items.biblionumber or biblio.biblionumber . 
___

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

Re: [Koha] [koha] Barcode as a link report

[Mark Alexander]

Excerpts from muirunyeri's message of 2020-05-18 13:05:56 +0300:
> I'm looking to create a report with barcode as a link that when will clicked 
> will open the edit items page.

There are some examples here that might help:

https://wiki.koha-community.org/wiki/SQL_Reports_Library#Links_by_item
___

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

Re: [Koha] Mark a batch of items as missing?

[Mark Alexander]

Excerpts from Katrin Fischer's message of 2020-03-26 16:28:05 +0100:
> check the settings for the subfield in your bibliographic frameworks and
> make sure it's not hidden.

Thank you for this hint.  It turns out that in the default bibliographic 
framework
in our installation (upgraded to 19.05.04), the 952$1 field (lost status) is 
hidden.
The manual warns against trying to edit the default framework, so I won't change
this setting.

Unfortunately, when I imported our catalog from Mandarin back in 2017,
I wasn't aware of this issue and all of those items seem to be using
the default framework.  Newer items added that I've added are using
the books framework, in which 952$1 is not hidden, so the lost status
appears in the item editor.
___

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

[Koha] Mark a batch of items as missing?

[Mark Alexander]

After doing some inventory in our library, I obtained a list of the
barcodes of a few dozen lost items.  Now I'd like use the batch item
modification tool to change the "lost status" for that set of items.
But I don't see a way to do that with this tool.  Is there another
way?  I'd like to avoid having to mark the items as missing one by
one.  I'll resort to SQL if necessary.

Thanks in advance!
___

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

Re: [Koha] Using Koha on Android devices for revision

[Mark Alexander]

Excerpts from asakov...@hmcpl.org's message of 2020-02-11 16:20:11 -0600:
> We’ve been evaluating the Tera Barcode Scanner Wireless 1D/2D/QR 2-in-1 unit 
> from Tera Digital (Germany).

Thank you for this recommendation.  I ordered the cheaper version of
this scanner that works only with 1D scancodes, which is all we need
at our library.  It makes the Koha inventory tool much easier to use:
I can walk around the library scanning books right at the shelf
instead of carrying the books to the computer and back.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] need help with accessing koha from outside via DynDNS

[Mark Alexander]

Excerpts from Heinz-Jürgen Oertel's message of 2020-02-06 13:32:34 +0100:
> I can reach my network vi   something.dnshome.de 
> With a port forwarding 80 -> 80 in the network router I can reach the test 
> page of the apache server.
> How  can I reach the koha server

It's possible that Koha is listening on a port other than 80.  This is
controlled by the VirtualHost line(s) in your Koha installation's
configuration file in /etc/apache2/sites-available/INSTANCE.conf, where INSTANCE
is the name of your Koha instance.

You can see what ports are in use with this command:

netstat -pn --tcp --listen | grep apache
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Printing overdue letters

[Mark Alexander]

Excerpts from SATISH's message of 2020-01-06 17:34:26 +0530:
> To overcome this problem, I have complied separate Library Dues Management
> System using PHP and MySQL.

Interesting.  I was thinking of doing something along these lines using
a Koha plugin.  I find plugins really difficult to debug (based on my
experience with writing a couple of simple ones), but it might be a little
easier for the staff at our little library to deal with.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Printing overdue letters

[Mark Alexander]

Excerpts from Mark Alexander's message of 2020-01-04 20:27:31 -0500:
> I think this might work, except that I can't figure out how to get a
> patron's list of overdue books into the generated letter.  The SQL
> would need to produce a CSV file with a single row for each patron,
> containing the patron name, address, and an arbitrarily long list of
> overdue books.

A kind person replied off-list and gave me the magic I needed:
GROUP_CONCAT.  Thanks!

In case anyone is interested, here is the SQL I ended up using:

SELECT p.cardnumber,
  CONCAT(p.firstname, ' ', p.surname) as name,
  p.address,
  CONCAT(p.city, ', ', p.state, ' ', p.zipcode) as city,
  GROUP_CONCAT(CONCAT_WS(' ', REPLACE(b.title, ' /', ''),
 CONCAT('$', i.replacementprice))
   SEPARATOR '; ') as overdues
FROM borrowers p
LEFT JOIN issues c ON (p.borrowernumber=c.borrowernumber)
LEFT JOIN items i ON (c.itemnumber=i.itemnumber)
INNER JOIN biblio b ON (i.biblionumber=b.biblionumber)
WHERE (TO_DAYS(curdate())-TO_DAYS(date_due)) >= <>
GROUP BY cardnumber
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Printing overdue letters

[Mark Alexander]

My librarian has asked me to make Koha do something that doesn't sound
easy to me.  She'd like to be able to generate letters to each patron
having overdues more than N days (where N is a variable).  The letter
would be then be printed, stuffed into an envelope, and mailed with
the postal service.  I know that sounds old-fashioned, but she seems
to really want to do this instead of using Koha's ability to email
notices and messages.  I can understand this, knowing that in this part
of rural New England, many of our patrons are elderly and either don't
have email, or have it but don't want to give us their email
addresses.

I am not sure I can do this in a simple SQL report, which generates
a table, not a form letter.  So my next idea was to write
a report that outputs the needed information (patron name, address,
list of overdue books and their replacement price).  Then I'd
export the results of the report to a CSV file.  Then I'd
do a mail merge in Libre Office Writer (or Word, which the
librarian uses) using the data in the CSV file.

The generated letter might look like this:

  To: PATRON_ADDRESS

  Dear PATRON_NAME,

  You have the following overdue books:

 BOOK1_TITLE, BOOK1_PRICE
 BOOK2_TITLE, BOOK1_PRICE
 ...

  Thanks,
  Your library


I think this might work, except that I can't figure out how to get a
patron's list of overdue books into the generated letter.  The SQL
would need to produce a CSV file with a single row for each patron,
containing the patron name, address, and an arbitrarily long list of
overdue books.  I am not sure that is possible, but then, my SQL
skills are not so great.

Any help with this would be appreciated greatly.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Cataloging tables, chairs, etc.

[Mark Alexander]

Many thanks to all who offered suggestions!  I've forwarded
them to our librarians (who are not on the mailing list).
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Cataloging tables, chairs, etc.

[Mark Alexander]

Our little library is planning to lend out things like folding tables, folding
chairs, cake pans, tools, and all sorts of other equipment.  I'm trying
to figure out the best way to set up circulation rules for these things.

My initial thought was to minimize the number of items types, and hence
circulations rules.  So we could have item types called "EQUIPMENT-3DAYS",
"EQUIPMENT-1WEEK", and "EQUIPMENT-1MONTH", the names of which reflect
how long the circulation period would be.  Then the various things
we could lend out would fall into one of these buckets.  But this means
that if a user was searching for items by item type in the OPAC, cake
pans might be listed next to power drills, and so forth.  Maybe that's OK;
I don't know.

I was wondering how other libraries deal with this kind of thing.

Thanks in advance!

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

Re: [Koha] R: Problem with browser

[Mark Alexander]

[I'm copying the mailing list in case the real experts have 
better advice.]

Excerpts from Davide Spanu's message of 2019-11-10 11:52:27 +0100:
> I have seen that to solve the problem I have to modify a file,
> eliminating the lines from 6 to 10 and add, in their place, the line
> "var popup = '[% popup | html%]';"

Actually, the patch describes the reverse of that.  It deletes this line:

   var popup = '[% popup | html %]';

and replaces it with these lines:

   [% IF popup %]
 var popup = true;
   [% ELSE %]
 var popup = false;
   [% END %]

> Can you tell me the name and path of the file to be modified on the server?

The file to be patched is here on 19.05:

  
/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/str/cataloging_additem.inc

I discovered this using the locate command:

  locate cataloging_additem.inc

Note that the locate command depends on a file location database being updated
regularly.  On my Debian installation, this wasn't being done as a cron job,
so I updated the database manually using this:

  updatedb

One way to patch the file without using an editor is to download the patch
to the directory in question 
(/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/str),
give it a name like additem.patch, and apply it using this command:

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

Re: [Koha] Problem with browser

[Mark Alexander]

Excerpts from Davide Spanu's message of 2019-11-10 09:58:08 +0100:
> I have a problem with my koha server. I realized that after
> importing a record (so before entering the copy data) the window of
> some browsers closes automatically (Chrome and Firefox). Before this
> problem did not occur (and I did not change any settings in either
> Koha or the server). Can you tell me what it can depend on? 

This is a known bug:

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

I manually applied the patch shown in comment 7 and that fixed the problem.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Creating Lists of Item Numbers

[Mark Alexander]

Excerpts from Charles Kelley's message of 2019-10-14 18:18:16 +0900:
> Can someone help me? Is there a tutorial on compiling item lists, bib.
> record lists, patron lists, etc.?

I believe that generating of lists is usually done with reports.
See this section of the Koha manual:

https://koha-community.org/manual/19.05/en/html/reports.html

Also see this page, which shows many sample reports:

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

Re: [Koha] Report help needed - lost items

[Mark Alexander]

Excerpts from Elaine Bradtke's message of 2019-08-23 11:32:44 -0700:
> I've got the following adapted from one in the reports library.  But I need
> to limit it by item type, or not return everything that doesn't have an
> item record attached. We've got lots of components in our catalogue that
> don't have items and it's returning all of them:
> 
> SELECT
> CONCAT(
> ' bib.biblionumber,
> '\">',
> bib.title,
> ''
> ) AS Title,
> bib.title,
> bib.biblionumber,
> lostitems.barcode,
> lostitems.ccode,
> lostitems.onloan AS 'Checkout date'
> FROM
> biblio bib
> LEFT JOIN items ON (bib.biblionumber = items.biblionumber AND
> items.itemlost = 0)
> LEFT JOIN items AS lostitems ON (bib.biblionumber =
> lostitems.biblionumber AND lostitems.itemlost != 0)
> GROUP BY bib.biblionumber
> HAVING count(items.itemnumber) = 0

While I'm not an SQL expert by any means, I think I was able to get
this to work on my catalog by removing the HAVING clause and
putting "WHERE items.itemnumber IS NULL" before the GROUP clause:

SELECT
CONCAT(
'',
bib.title,
''
) AS Title,
bib.title,
bib.biblionumber,
lostitems.barcode,
lostitems.ccode,
lostitems.onloan AS 'Checkout date'
FROM
biblio bib
LEFT JOIN items ON (bib.biblionumber = items.biblionumber AND
items.itemlost = 0)
LEFT JOIN items AS lostitems ON (bib.biblionumber =
lostitems.biblionumber AND lostitems.itemlost != 0)
WHERE items.itemnumber IS NULL 
GROUP BY bib.biblionumber
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha 18.11

[Mark Alexander]

Excerpts from Luisa Korodrau's message of 2019-04-19 08:12:05 +1200:
> 1. uploading photos for patrons record. The photo uploading icon is not
> there.  Where can I find it and how is it done

Have you set the "patronimages" system preference to "allow"?  There is some
information here:

https://koha-community.org/manual/18.11/en/html/patrons.html?highlight=patronimages#add-patron-images
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] New OPAC design

[Mark Alexander]

This is wonderful work.  We're going to adopt it at our little rural
library, since most of our patrons are over 50, and we need to encourage
more young people to visit.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha importing biblio with items error

[Mark Alexander]

Excerpts from Dorothy Chong's message of 2019-02-12 20:14:48 +0800:
> Our library is hoping to transfer into Koha but has so far had issues with 
> staging the records with items. Without the 952 field it works fine, and it 
> also worked fine when it was just 952$a, $b, and $y. Whenever I try to stage 
> the file it just comes back with “fail to submit form: error”. What is the 
> problem with my MARC please?
> [...]
> =952  \\$a[library name]$b[library name]$o001.94 WIL$p06$yBook

I've run into import problems when either the library name or the
item type was invalid.

Make sure that "Book" is valid by visiting More / Administration /
Basic Parameters / Item types.  It should be one of the values in the
"Code" column.

Similarly, make sure that your library name is correct by visiting
More / Administration / Basic Parameters / Libraries.  The library
name should be one of values in the "Code" column.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha Duplicating Items

[Mark Alexander]

Excerpts from Myriam Torres's message of 2019-02-12 11:22:18 +0200:
> [...] The problem is that instead of creating a single item with
> all the information it creates many items with different information. This
> is my mrc file:
> [...]
> =952  \\$aAKL
> =952  \\$bAKL
> =952  \\$o005.265
> =952  \\$p0014915
> =952  \\$yBK

The problem is that Koha treats each 952 field as a separate item.
So in this example, you have five item records instead of one.
You will need to merge each 952 subfield into a single 952 field,
like this:

  =952  \\$aAKL \\$bAKL \\$o005.265 \\$p0014915 \\$yBK

(Apologies if I have the syntax wrong; I use my own scripts
instead of Marcedit.)
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] OPAC holdings table in 18.11 shows instead of blank

[Mark Alexander]

Excerpts from Mark Alexander's message of 2018-12-22 11:56:33 -0500:
> In the OPAC, when looking at the MARC view for an item, there is a
> table at the bottom of the page showing some holding information.
> Those table fields that used to be blank in 18.05 are now displaying
> as "" (without the quotes) in 18.11.

After some searching, I believe this may be related to bug 13618.
I also looked at 21947, but that seems like a different issue
related to the changes for 13618.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] OPAC holdings table in 18.11 shows instead of blank

[Mark Alexander]

I've just upgraded one of my Koha VMs from 18.05 to 18.11, and also
created a new install of 18.11 in another VM, and both exibit a new
issue:

In the OPAC, when looking at the MARC view for an item, there is a
table at the bottom of the page showing some holding information.
Those table fields that used to be blank in 18.05 are now displaying
as "" (without the quotes) in 18.11.  In my particular case, the
fields that are displayed this way are:

* Withdrawn status
* Lost status
* Damaged status
* Not for loan

I have uploaded some screen shots here:

http://www.bloovis.com/artemis-18.05.png
http://www.bloovis.com/artemis-18.11.png

I tried to find something in Bugzilla about this but was not successful.
Is this a known problem?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Matric Number and Barcode not Showing on Library Card

[Mark Alexander]

Excerpts from olufunmilayo favour's message of 2018-11-07 08:01:57 +:

> I configured my university's koha library card and it works
> perfectly for the undergraduate students whose matriculation numbers
> are in this format AAA/12345678 and varchar was selected for the type
> at PHPMyAdmin. However, using the same card layout, for the
> postgraduate students whose matriculation numbers are in the format
> BBB/pg/17/, the matriculation numbers (card numbers) and the
> barcode do not come out when the cards are printed. Card numbers are
> supposed to be printed printed as barcode. Our Koha LMS is Ubuntu OS
> based. 

> Can someone tell me what the problem is and suggest how to go round it please?

I suspect the problem is that the card numbers include lower case letters 
("pg").
If your card layout uses Code 39 for the barcode, that won't work because
Code 39 does not allow lower case letters.  See this:

  https://en.wikipedia.org/wiki/Code_39

I tried this on my own system, and verified this behavior.  However, when I 
changed
the card layout to use Code 39 + Modulo43 as the barcode format, which does 
support
lower case letters, Koha gave this error when I tried to export a library card 
batch:

  WARNING: Error while creating PDF file. Batch: 1 Layout: 1 Template: 1
  Please have your system administrator check the error log for details. 

I examined plack-error.log but didn't see anything that I could readily
understand as related to the problem.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Reservoir records deletion

[Mark Alexander]

Excerpts from Hira Akram's message of 2018-08-09 17:30:07 +0500:
> I want to delete all biblio records from my koha but they are still appearing 
> in reservoir. How to remove them? I have deleted them from catalogue and they 
> are not imported so I cant clean the batch.

This is how I did it:

  koha-shell LIB  # LIB is your Koha instance name
  /usr/share/koha/bin/cronjobs/cleanup_database.pl --import 60 -v

Here is what the --help option says about this:

   --import DAYS  purge records from import tables older than DAYS days.
  Defaults to 60 days if no days specified.

Also see:

  http://koha.1045719.n5.nabble.com/Biblios-in-reservoir-td5965405.html
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] 18.05.01 up gradation login access denied

[Mark Alexander]

Excerpts from Arshad Iqbal's message of 2018-07-16 17:59:22 +0500:
> I have upgraded koha version 16.05 to 18.05.01. After  upgraded i am trying
> to login with master username and password but access denied to login error
> facing.

This is described in the release notes for 18.05:

https://koha-community.org/koha-18-05-released/

Quote:

It is no longer possible to use the database user (defined in
koha-conf.xml) to login into Koha.  You should first create a
superlibrarian patron and use it for logging in.
See the script misc/devel/create_superlibrarian.pl

Also see this bug:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20489
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] zebra shutting down - no search

[Mark Alexander]

Excerpts from Scott Owen's message of 2018-06-21 09:16:56 -0400:
> I still seem to be having some issues with logrotate and the zebra service
> starting up
> 
> I have tried both of the options discussed in bug #
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16885

I was able to solve this problem by disabling anacron, as described here:

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

Re: [Koha] Migration from Mandarin to Koha

[Mark Alexander]

Excerpts from Mr Mutsikiwa Admire's message of 2018-06-15 16:55:38 +0200:
> I want to migrate bibliographic records from a Mandarin to Koha. 
> Currently, I am guided by the resource 
> http://www.bloovis.com/2017/08/09/mandarin-to-koha.html. I am wondering 
> if there are any generic resources that could aid in the migration 
> process.

I am the author of that guide (which may be slightly out of date,
since I wrote it almost a year ago).  I had to develop my own
Mandarin-to-Koha migration scripts because I couldn't find any existing
tools to do the job.

Are you having problems with the scripts I wrote?  If so, feel free
to write to me privately and I may be able to help.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] SQL Report not populating

[Mark Alexander]

I tried your query with the WHERE clause slightly simplified to
give a non-empty result on my test installation of 18.05:

  WHERE (TO_DAYS(curdate())-TO_DAYS(date_due)) >= ''

I was then able to download the CSV file and read it into LibreOffice
Calc with no problems.

So your query looks good; maybe take a look at the CSV file in
an editor to see if there's anything strange about it.  Or perhaps
you have to tell your CSV import tool to use commas, and not semicolons
or other delimiters (LibreOffice has several options for this).
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] ssl for koha login

[Mark Alexander]

Excerpts from Alvaro Cornejo's message of 2018-06-04 21:18:57 -0500:
> I´m trying to setup a ssl connection to Koha  (using letsEncrypt certs ) so
> my users, admin and opac can have a secure connection.
> 
> I´ve folllowed letsEncrypt & certbot instrucctions but neither opac nor
> admin pages work.

I used certbot on Debian 8 to get the OPAC and staff clients to use
SSL.  If I recall correctly, certbot attempted to modify my Apache
config file to add references to the LetsEncrypt certificate files,
but I think it chose the wrong file to modify.  So I hand-modified the
Koha-specific config file to point to the certificates.

Below is the resulting /etc/apache2/sites-available/LIB.conf.  Replace
LIB with the actual Koha instance name, and replace KOHA.MYLIBRARY.COM
with the actual hostname.  Note also that I chose port 81 for the OPAC
and port 82 for the staff client; you will probably need to change
those numbers.

# Koha instance LIB Apache config.

# OPAC

  = 2.4>
   Define instance "LIB"
  
   Include /etc/koha/apache-shared.conf
#  Include /etc/koha/apache-shared-disable.conf
  Include /etc/koha/apache-shared-opac-plack.conf
   Include /etc/koha/apache-shared-opac.conf

   ServerName KOHA.MYLIBRARY.COM
   SetEnv KOHA_CONF "/etc/koha/sites/LIB/koha-conf.xml"
   SetEnv MEMCACHED_SERVERS "127.0.0.1:11211"
   SetEnv MEMCACHED_NAMESPACE "koha_LIB"
   AssignUserID LIB-koha LIB-koha

   ErrorLog/var/log/koha/LIB/opac-error.log
#  TransferLog /var/log/koha/LIB/opac-access.log
#  RewriteLog  /var/log/koha/LIB/opac-rewrite.log
SSLCertificateFile /etc/letsencrypt/live/KOHA.MYLIBRARY.COM/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/KOHA.MYLIBRARY.COM/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf


# Intranet

  = 2.4>
   Define instance "LIB"
  
   Include /etc/koha/apache-shared.conf
#  Include /etc/koha/apache-shared-disable.conf
  Include /etc/koha/apache-shared-intranet-plack.conf
   Include /etc/koha/apache-shared-intranet.conf
   
   ServerName KOHA.MYLIBRARY.COM
   SetEnv KOHA_CONF "/etc/koha/sites/LIB/koha-conf.xml"
   SetEnv MEMCACHED_SERVERS "127.0.0.1:11211"
   SetEnv MEMCACHED_NAMESPACE "koha_LIB"
   AssignUserID LIB-koha LIB-koha

   ErrorLog/var/log/koha/LIB/intranet-error.log
#  TransferLog /var/log/koha/LIB/intranet-access.log
#  RewriteLog  /var/log/koha/LIB/intranet-rewrite.log
SSLCertificateFile /etc/letsencrypt/live/KOHA.MYLIBRARY.COM/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/KOHA.MYLIBRARY.COM/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

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

Re: [Koha] Fwd: OPAC Page not available and login credentials don't work

[Mark Alexander]

Excerpts from Bedanta Borah's message of 2018-05-28 10:45:54 -0700:
> 2) In case of  koha livedvd, all features were doing fine untill I updated
> the system and the koha-common packages. After the update, my root user and
> password (koha_library & koha123) stopped working. But I can login with
> another patron which I had created before the update was done. Why I loose
> database user access after updating the software?
> 
> Q) How can I regain the database user access?

I'm not sure if the following will help, but I did notice something
that may be related in the release notes for 18.05 here:

  https://koha-community.org/koha-18-05-released/

Here is what they say about this issue:

  No more login with the database user

  It is no longer possible to use the database user to login into Koha.
  You should first create a superlibrarian patron and use it for logging in.
  [...]
  It is no longer possible to use the database user (defined in koha-conf.xml) 
to login into Koha.
  You should first create a superlibrarian patron and use it for logging in.
  See the script misc/devel/create_superlibrarian.pl

This was discussed in this bug:

  https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20489
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Importing MARC records with items

[Mark Alexander]

Excerpts from Sean Carte's message of 2018-04-18 10:44:45 +0200:
> I have records that I have exported from SirsiDynix Symphony that I'm
> trying to import into a new instance of Koha. The bib records load, but the
> items are not added.
>[...]
> 952
> 
> *_a*657 GAA V.1

This doesn't look quite right to me.  According to the holdings table
in the wiki:

https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx)

952$a and 952$b should contain the branch codes for owning library
and holding library, respectively.  Your 952$a doesn't look like
a branch code, and I don't see a 952$b.

When I imported our Mandarin catalog to Koha, my script set the following
rather minimal holding fields, and that seemed to be enough:

 942$c - item type
 952$8 - collection code
 952$a - owning library
 952$b - holding library
 952$c - location code
 952$d - acquisition date
 952$o - call number
 952$p - barcode
 952$v - price
 952$y - item type

Note that you need to have previously set up the authorized values for 
collection
codes and location codes for this to work.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] added new library branch -- lost all collections

[Mark Alexander]

Excerpts from Jack Boulier's message of 2018-04-11 04:25:23 +:
> I have ubuntu xenial and koha 17.11.04. I added a new library to the database 
> and added some books to that library. When I did a search for the text I 
> could not find them as a superuser. The search would always query the 
> original database and not the new branch. In the database I was able to 
> locate the records with an SQL query. I attempted to run the 
> koha-rebuild-zebra library attempting to get the collection updated. Now I 
> have lost the entire collection. However the database is still complete in 
> mariadb.
> Now I can not locate any items in the database.

As an experiment, try using the advanced search in the staff client
(cgi-bin/koha/catalogue/search.pl). Then under the headings
"Location and availability" and "Individual libraries", try selecting
your new library and redoing the search.  Maybe this won't help, but it
would be a data point in the debugging process.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Zebra stops every day

[Mark Alexander]

Excerpts from Javed Sahil's message of 2018-04-04 17:44:23 +:
> I am using Koha17.11, I moved my old DB which was working fine in koha16.11,
> 
> But now my zebra server stops daily or after two or three days,  actually
> i have not noted exact duration.

It might be this problem:

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

If so, this is the solution that worked for me:

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

Re: [Koha] Koha Performance

[Mark Alexander]

Excerpts from Narcis Garcia's message of 2018-03-20 10:38:26 +0100:
> 1. What is the concrete indicator that Plack is enabled and running or not?

In the "About Koha" page, immediately after the "Apache version:" line, you 
should
see a line that looks like this:

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

Re: [Koha] Out of memory

[Mark Alexander]

Excerpts from Rubeno Fernández's message of 2018-03-19 07:12:29 +0100:
> How much memory do you need to run Koha?
> I run a database with about 22000 records on a virtual server on Digital 
> Ocean 
> with 1GB memory and very low usage, but the server is crashing very often.

We're running Koha 17.11.02 on Linode (Debian 8) with 2 GB of RAM, and
our library has about 25000 item records.  So far we haven't had any out
of memory problems.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] DDoS attack on memcached

[Mark Alexander]

Apparently, a bug in memcached (which we use in Koha) causes it to be
used an intermediary in a DDoS attack:

https://arstechnica.com/information-technology/2018/02/in-the-wild-ddoses-use-new-way-to-achieve-unthinkable-sizes/

I'm not an expert on this kind of thing by any means, but judging
from this:

  https://github.com/memcached/memcached/wiki/ReleaseNotes156

It seems that we can disable the attack by preventing memcached from
listening on a UDP port.  I was able to do this by adding the
following lines to /etc/memcached.conf:

  # Disable UDP
  -U 0

Then restarted memcached and apache2.

My questions for the experts: Is this the correct approach?  Is it even 
necessary?
Is there more we should do?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Export from one library, Import to another?

[Mark Alexander]

Excerpts from Alvin W.'s message of 2018-01-15 16:43:12 -0500:
> Basically, I don't care about the content, I just want a verified file that
> I was able to Import correctly, to serve as a baseline for the actual
> collection when I load it, so that if errors occur, it should be easier to
> figure out exactly what went wrong.

I had to go through this process when I converted our library
from Mandarin to Koha.  Mandarin exported its catalog in MARC
format, but I had to do a fair amount of work (using scripts that
I wrote) to modify the holding fields so that Koha would accept them.

A good starting point for understanding the issues is this
document:

https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx)

You'll notice that a number of the fields (such as collection code,
branchcode, shelving location code, and Koha item type) will need to
have values that match values that you have previously set up in Koha.
Collection code and shelving location code must match authorized
values for CCODE and LOC, respectively.  The branchcode must match
codes that you've set up for library branches.  The item type must
match the item types you've set up.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] SQL help

[Mark Alexander]

Excerpts from Elaine Bradtke's message of 2018-01-09 11:06:16 -0800:
> "Unknown column 'place' in 'field list'"
> Here's the report - what field name do I need to replace place?:
> select
>   b.biblionumber, author, title,
>   ExtractValue(metadata, '//datafield[@tag="245"]/subfield[@code="b"]') as
> subtitle,
>   ExtractValue(metadata, '//datafield[@tag="250"]/subfield[@code="a"]') as
> edition,
>   copyrightdate, place, publishercode, isbn
> from
>   items as a
> left join
>   biblio_metadata as b on (a.biblioitemnumber = b.biblioitemnumber)
> left join
>   biblio as c on (b.biblionumber = c.biblionumber)
> where
>   itype = 'BK' and holdingbranch = 'VWML'
> order by author asc

I took a look at the 17.05 schema here: 
http://schema.koha-community.org/17_05/index.html.
It seems that some things have been moved to biblioitems, though I'm not
familiar with the history.

I was able to get your query to work (or at least, not give errors) by
rewriting it as follows:

select
  biblionumber,
  biblio.author,
  biblio.title,
  ExtractValue(biblio_metadata.metadata, 
'//datafield[@tag="245"]/subfield[@code="b"]') as subtitle,
  ExtractValue(biblio_metadata.metadata, 
'//datafield[@tag="250"]/subfield[@code="a"]') as edition,
  biblio.copyrightdate,
  biblioitems.place,
  biblioitems.publishercode,
  biblioitems.isbn
  from items
  left join biblioitems using (biblionumber)
  left join biblio_metadata using (biblionumber)
  left join biblio using (biblionumber)
  where  itype = 'BK' and holdingbranch = 'VWML'
  order by author asc;
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Problems adding new members in 17.11

[Mark Alexander]

Excerpts from Tim McMahon's message of 2018-01-02 16:26:39 -0600:
> I'm testing 17.11 (package upgrade from 17.05.02) and when I try to 
> enter a new patron, the Password and Confirm password fields in the 
> OPAC/Staff login section near the bottom of the form will get labeled 
> "This field is required."

I can confirm this behavior on my test VM of 17.11

Curiously, during my test of adding a new patron, the "required"
labels on the Password and Confirm fields didn't appear when I first
loaded the form. They only showed up after I hit the "Save" button,
which failed to save, and presented me with the form again, this time
with the labels added.

I got around the problem by putting the word "junk" in for the
passwords, and leaving the username blank.  Then when I edited that
patron again, I found that Koha had auto-generated a user name
consisting of the first and last names of the patron concatenated with
a "." separator.

In summary, I couldn't find a way to enter blank usernames or passwords
for patrons.  I don't recall that 17.05 exhibited this behavior.

> I also noticed that the primary and secondary email fields aren't 
> validating either.

I didn't see a problem with these fields.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Can't locate LangInstaller.pm in @INC

[Mark Alexander]

> > root@srv2:/usr/share/koha/misc/translator# perl 
> > -I/usr/share/koha/misc/translator translate install it-IT
> > Can't locate TmplTokenizer.pm in @INC (you may need to install the 
> > TmplTokenizer module) (@INC contains: /usr/share/koha/lib /etc/perl 
> > /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
> > /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 
> > /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 
> > /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
> > /usr/share/koha/misc/translator/tmpl_process3.pl line 20.
[...]
> sudo koha-shell instancename

This problem comes up so frequently that I wonder if the scripts
could check for it and suggest a fix, along these lines:

if (!defined($ENV{KOHA_CONF}) && !defined($ENV{PERL5LIB})) {
   die("Please run koha-shell first.");
}
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Import of .KOC file into Koha 17.11 hangs

[Mark Alexander]

Excerpts from Chris Brown's message of 2017-12-27 17:03:17 +:
> Using a fresh install of Koha 17.11.00 (from Debian packages) I have
> successfully loaded our patron data, our catalog and our items. However
> when I try to import an offline circulation (.koc) file, nothing happens.
> The progress bar sits at 0% and nothing is imported.

I just tried this with a six-entry .koc file on a test installation of
17.11.00 in a VM and it seemed to work.  The progress bar did stay at
0% for a lengthy period, maybe 15 seconds, which was a little
alarming.  During that time, the VM seemed quite CPU-bound and I
couldn't ssh into it; this might be due to the fact that the VM had
only 1 GB of RAM.  But eventually it did complete and reported that
"your data was processed" along with a list of the processed items.

Here's what my test file looked like, in case that might help.  Note
that there are tabs separating the fields, not spaces.  Note also that
this file was generated by a script I wrote to convert a Mandarin loan
report to .koc, hence the funny looking timestamps.

Version=1.0 Generator=pdf2koc.rbGeneratorVersion=0.1
2017-08-05 12:30:00 0   issue   R7306   RPL24055
2015-07-09 12:30:00 1   issue   R1786   RPL26855
2017-07-25 12:30:00 2   issue   R1786   RPL22690
2017-08-01 12:30:00 3   issue   R1786   RPL24021
2017-08-01 12:30:00 4   issue   R1786   RPL23969
2017-08-01 12:30:00 5   issue   R1786   RPL28030
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] ILS Z39.50 server information where to look for?

[Mark Alexander]

Excerpts from Bustillos, Corina's message of 2017-12-15 19:20:55 +:
> I was wondering if anyone knows where I can find the following information 
> within KOHA.
> IP address of the ILS Z39.50 server
> Port that Ze9.50 searches use
> Database name.

By default the Z39.50 server has the same IP address as your Koha
server, port 9998, database biblios.  The port and database are
defined in /etc/koha/sites/LIBRARY/koha-conf.xml, where LIBRARY is the
Koha instance name. 

You can test this using this:

  yaz-client mylibrary.example.com:9998/biblios

Replace mylibrary.example.com with your actual hostname or IP address.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] SQL help please

[Mark Alexander]

Excerpts from Pedro Amorim's message of 2017-12-11 14:18:08 -0100:
> This should work:
> 
> Select title, author, i.itemcallnumber from biblio b
> Left join biblioitems bi on b.biblionumber=bi.biblionumber
> Left join items i on bi.biblionumber=i.biblionumber
> where i.barcode IN ("BARCODE1", "BARCODE2", "BARCODE3");

This can also be made into an SQL report using multiple entry fields
for the barcodes.  It's a bit of a kludge but seems to work because
the blank fields are treated either as '' or NULL in the generated SQL.

Select title, author, i.itemcallnumber from biblio b
Left join biblioitems bi on b.biblionumber=bi.biblionumber
Left join items i on bi.biblionumber=i.biblionumber
where i.barcode = <>
or i.barcode = <>
or i.barcode = <>
or i.barcode = <>
or i.barcode = <>
or i.barcode = <>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Can't run auth_show_hidden_data.pl script

[Mark Alexander]

Excerpts from Prof. Lisandro Laura's message of 2017-12-06 11:41:57 -0300:
> perl ./usr/share/koha/bin/maintenance/auth_show_hidden_data.pl
> 
> But I get the following error:
> 
> "Can't locate Koha/Authorities.pm in @INC (you may need to install the
> Koha::Authorities module) (@INC contains: /etc/perl

This sounds familiar.  Try running the following command first:

  koha-shell LIBRARY

where LIBRARY is your Koha instance name.  After that, the various
Koha shell scripts should work.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Email status changes failed from pending

[Mark Alexander]

Excerpts from Javed Sahil's message of 2017-12-03 16:05:23 +0500:
> 5../process_message_queue.pl
> 
> this error message appears:
> 
> connect to localhost failed (Connection refused)

This sounds to me like a postfix configuration problem.

What happens when you try this?

  telnet localhost 25

This should connect to the postfix SMTP server.

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

Re: [Koha] koha not sending email notices for Check in, Check out, Overdue etc.

[Mark Alexander]

Excerpts from Javed Sahil's message of 2017-12-01 12:36:37 +0500:
> *# PERL5LIB="/usr/share/koha/lib"#
> KOHA_CONF="/etc/koha/sites/library/koha-conf.xml"# cd
> /usr/share/koha/bin/cronjobs*
> 
> above commands go fine but when i try the following command,
> 
> *# ./*process_message_queue.pl
> 
> it returns
> 
> unable to locate Koha configuration file koha-conf.xml at
> /usr/share/koha/lib/C4/Context.pm line 242.

Try using this command first:

   koha-shell LIBRARY

where LIBRARY is your Koha instance name.  This should set
up the environment correctly to run the various scripts.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Regexp in MARC modification action

[Mark Alexander]

Excerpts from Jonathan Druart's message of 2017-11-26 16:45:08 +:
> The "ig" in the modifiers input is a placeholder, not the default.
> It is displayed as it to let you know 'i' and/or 'g' are possible modifiers.
> Please try again explicitly specifying "ig" in the input box and it should
> work.

Thanks, that worked.  I was confused by the faint gray "ig" in the input box
because I thought that field wasn't editable.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] OAI-PMH Set Question

[Mark Alexander]

Excerpts from Alphie Garcia's message of 2017-11-22 09:56:03 -1000:
> When I'm in Linux and type:
> 
> perl /usr/share/koha/bin/migration_tools/build_oai_sets.pl
> 
> 
> I get the following error:
> 
> Can't locate C4/Context.pm in @INC (you may need to install the C4::Context
> module) (@INC contains: /etc/perl

Try running this command first:

  koha-shell INSTANCE

where INSTANCE is the name of your Koha instance.  That should set up
the environment so that the build_oai_sets.pl script will run correctly.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Regexp in MARC modification action

[Mark Alexander]

I'm trying to use a MARC modification template to fix the 952$d field
in MARC records we receive from our library supply house.  This field
is supposed to be the acquisition date, but is coming to us in the
format /MM/DD instead of the required -MM-DD.  So I needed to
find a way to replace the slashes with dashes. 

I created a MARC modification template with a simple action that uses
the regular expression s/\//-/ig.  The UI for creating the action in
Koha implies that the "ig" modifiers are always used (though there
doesn't seem to be any way to change them).  My understanding of the
"g" modifier in Perl is that it causes the s// operator to "replace
globally, that is, all occurrences".  (This is a quote from an old
copy of "Programming Perl" by Wall et. al.)

Yet it doesn't seem that the "g" modifier is really being used.  When
I used this template on an imported MARC record, it changed the first
slash in 952$d, but not the second one.  So, for example, 2017/11/06
got changed to 2017-11/06.  I had to add a second action to the
template, identical to the first action, to cause the second slash to be
replaced. 

Am I misunderstanding the use of regular expressions in MARC
modification templates, and in particular the behavior of the "g"
modifier?  Or is this a possible bug?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Z39.50, ILL, and 952$r

[Mark Alexander]

Excerpts from Tomas Cohen Arazi's message of 2017-09-21 23:44:56 +:
> Wow. I hadn't noticed that new feature!

I applied the patches to our Koha installation and it does seem to work
when I invoke the server as follows:

  koha-shell 
  cd /usr/share/koha
  perl bin/z3950_responder.pl --add-item-status=k tcp:@:

I realize that patching an installation made from a Debian package is
not recommended, but I'm comfortable with this sort of thing, and I was
in a bit of a hurry to fix the ILL problem.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Z39.50, ILL, and 952$r

[Mark Alexander]

Excerpts from Jason Robb's message of 2017-09-21 16:53:16 -0500:
> Along with the other systems that use Koha in Kansas, we have worked with
> ByWater on this. You can see the details here: https://bugs.koha-
> community.org/bugzilla3/show_bug.cgi?id=13937. The basic idea is that
> whenever a z39.50 request is made, Koha will populate a status into a
> singular subfield that can be mapped and read by the external ILL software.

Thanks!  I ran across that bug a few minutes before I saw your reply.
The proposed solution looks good.  Is there a plan to incorporate it
eventually into the official Debian package?
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Z39.50, ILL, and 952$r

[Mark Alexander]

I made a silly mistake in my previous message: I meant 952$q (onloan),
not 952$r (datelastseen).
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Z39.50, ILL, and 952$r

[Mark Alexander]

Our little state (hint: starts with "V") has implemented an
interlibrary loan system that seems to be unable to use Z39.50
correctly to query Koha in order to determine an item's availability.
I'll try to describe the problem and then ask if there's a workaround
in Koha.

The state ILL system, called CLOVER, is able to use Z39.50 to query
our library's Koha installation to determine whether an item is in our
catalog.  We told the state to use the MARC 952$r field returned by
Koha (actually Zebra, if I understand correctly) to determine whether
the item is available.  This field contains the item's due date.  If
it is present and contains a date, the item is NOT available.  If it
is not present, the item IS available.

But apparently, CLOVER is not able to handle a MARC field that is
present sometimes and not at other times.  It requires that the field
be present ALL the time.  That is the explanation given to us by the
state when we asked why CLOVER wasn't working correctly (it keeps
issuing requests for books that it had already requested).  This seems
like a serious bug, because there are at least 80 other Koha
installations in our state.  Unfortunately, CLOVER is closed-source
and proprietary, so there seems to be no way for the state to fix the
problem.

Is there some workaround that I can implement in Koha and/or Zebra to
force the 952$r field to be present in all records returned in
response a Z39.50 query?  I think CLOVER might work if 952$r were
present but blank for items that are available.

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

Re: [Koha] Hide MARC View separator

[Mark Alexander]

Excerpts from | dalmeida |'s message of 2017-09-16 18:57:03 +0100:
> Does anyone know how to hide MARC View separator on book Details page? I'd
> like to have only Normal View and ISBD View.

I used the following as a hint:

  
https://wiki.koha-community.org/wiki/JQuery_Library#Hide_Marc_.26_ISBD_view_from_OPAC

which recommended using:

  $(".view a:contains('MARC view')").hide();

But using Firefox's "Inspect Element" feature, I saw that the "MARC view" tab
has an ID of "MARCview".  So I was able to simplify the Javascript in
OPACUserJS preference to the following:

  $(document).ready(function(){
$("#MARCview").hide();
  });

Note: I tested this only on 17.05.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Data not found

[Mark Alexander]

Excerpts from Luis Moises Rojas's message of 2017-09-15 09:23:17 -0400:
> Everyday in the morning, i have to run this script:
> Koha-rebuild-zebra -f -v -b -r {Koha instance}
> 
> if i do not do this: we can not see any data, not search is found, etc.
> Why?

It could be that the zebra server is not running.  Try this:

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

[Koha] Kitchen sink plugin and GetBranchName

[Mark Alexander]

In order to learn how to write a plugin, I installed the Kitchen sink plugin:

  https://github.com/bywatersolutions/koha-plugin-kitchen-sink

into stock Koha 17.05.  When I ran the plugin's report tool, I got
this error:

  Undefined subroutine 
::Plugin::Com::ByWaterSolutions::KitchenSink::GetBranchName called at 
/var/lib/koha/rpl/plugins/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm line 
372.

The code in question is this:

$template->param(
date_ran => dt_from_string(),
results_loop => \@results,
branch   => GetBranchName($branch),
);

After poking around in the Koha git repository, I saw that GetBranchName
was removed by this commit:

  commit 19a977dc7b779173c4a3e96b6b06dc35db663601
  Author: Jonathan Druart 
  Date:   Tue Feb 2 17:28:30 2016 +

  Bug 15758: Koha::Libraries - Remove GetBranchName

I was able to fix the plugin by replacing the line with the GetBranchName call
with this line:

branch   => Koha::Libraries->find($branch)->branchname,
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] 4 Perl Modules Not Installed on Koha 17.05.03.000

[Mark Alexander]

Excerpts from Mark Tompsett's message of 2017-09-05 14:10:59 +:
> The major problem with cpan'ing your modules is that if you cpan them, and 
> then a newer version comes out with a fix/enhancement, the search paths used 
> by Perl will more likely find your CPAN'd versions rather than the DEB'd 
> versions. This is why cpan2deb (or the 3rd suggestion) is what I tend to do 
> if the first 2 ways don't work.

Thanks, that helps.  cpan2deb worked for me.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] 4 Perl Modules Not Installed on Koha 17.05.03.000

[Mark Alexander]

Excerpts from Mark Tompsett's message of 2017-09-05 03:57:06 +:
> > WebService::ILS (0.07)
> 
> On newer versions this is the only one that you will probably care about.

Can you explain what this module is used for in Koha?  It was missing
in my installations of 17.05.03, but Koha seemed happy without it.

On my test VM, I installed it using 'cpan -i WebService::ILS'.
Is there any reason why this method isn't mentioned on this page?

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

Re: [Koha] Koha 16.11.04 - Setting a template cache directory

[Mark Alexander]

Excerpts from Prof. Lisandro Laura's message of 2017-08-26 11:05:34 -0300:
> Could anyone please point me to a simple step by step instruction to
> set  entry in my koha-conf.xml file?

As I mentioned in my earlier email, I created the cache directory as follows:

  mkdir -p /var/cache/koha/INSTANCE/templates
  chown INSTANCE-koha:INSTANCE-koha /var/cache/koha/INSTANCE/templates

Then I added the following line at the end of the  section
in /etc/koha/sites/INSTANCE/koha-conf.xml:

 /var/cache/koha/INSTANCE/templates

In all of the above instructions, replace INSTANCE with your actual
library instance name.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] How to import loans data into Koha?

[Mark Alexander]

Excerpts from Mark Alexander's message of 2017-08-15 19:03:46 -0400:
> Excerpts from Chris Brown's message of 2017-08-15 21:06:52 +0100:
> > [...] but I was wondering if
> > there is a way to import data on current issues (loans)?  All we really
> > need to import is the item ID, the patron ID and the due-back date.
> 
> I did this by writing a script to convert the loan list generated by
> our our old library system (Mandarin) into a KOC file (Koha Offline
> Circulation File), and then importing that. [...]

I forgot to mention that each row in the the KOC file has a date, but
it is the issue date, not the due-back date.  When Koha imports the
file, it will calculate the due-back dates using the circulation rules
that you should have already defined.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] How to import loans data into Koha?

[Mark Alexander]

Excerpts from Chris Brown's message of 2017-08-15 21:06:52 +0100:
> We are migrating records from a few small community libraries (currently
> held as a fancy spreadsheet) into Koha 17.05. I have figured out how to
> migrate the biblio records, items and patron data but I was wondering if
> there is a way to import data on current issues (loans)?  All we really
> need to import is the item ID, the patron ID and the due-back date.

I did this by writing a script to convert the loan list generated by
our our old library system (Mandarin) into a KOC file (Koha Offline
Circulation File), and then importing that.  The KOC file format is
defined here:

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

Re: [Koha] Import holds?

[Mark Alexander]

Excerpts from Katrin Fischer's message of 2017-08-15 12:47:45 +0200:
> holds information is stored differently in every ILS and at the moment 
> there exists no generic tool to import holds into Koha. For a migration 
> you could try to map the data you get out of Mandarin to the columns in 
> Koha's reserves table and then use a script or SQL to fill it. It can be 
> useful to place a few different holds in Koha first to see what data is 
> required/set by Koha itself.

Thank you.  That makes sense, and I was already thinking of doing
something like this.  But there aren't a large number of holds, and it
might be less time-consuming to enter them manually than to study the
database tables and write the script.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Import holds?

[Mark Alexander]

Our little (24K items) library has successfully moved from Mandarin to
Koha as of Tuesday.  I was able to import the catalog, patrons, and
checkouts (issues) from Mandarin by writing scripts to convert
Mandarin-generated data to Koha-compatible data.

The one missing thing is holds (reserves).  I'm still looking for a
way to generate a holds report in Mandarin, but assuming I can
generate such a report, I don't see a way to import hold information
into Koha.  I was able to use KOC files to import issues, but the KOC
file format doesn't support holds.  I was wondering if there is some
other way to import holds programmatically, or if anyone else has had
to deal with this problem when migrating to Koha.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Patron Club feature

[Mark Alexander]

Excerpts from Krishna K's message of 2017-07-30 06:02:15 +:
> We recently upgraded to 17.05.01 from 16.11.05. When we try to use the
> clubs feature by clicking on Tools-> Patron Clubs link, we are getting 404
> error. We dont seem to be having the clubs.pl file. What should we do ?
> Appreciate your inputs.

[Apologies if this is a dupe message; my previous reply seems to
have been rejected by the list server.]

I think there may be problem with the koha-common package.  I don't
see clubs.pl in there:

  % dpkg -L koha-common | egrep clubs
  /usr/share/koha/opac/cgi-bin/opac/clubs
  /usr/share/koha/opac/cgi-bin/opac/clubs/clubs-tab.pl
  /usr/share/koha/opac/cgi-bin/opac/clubs/enroll.pl
  /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/modules/clubs
  /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/modules/clubs/clubs-tab.tt
  /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/modules/clubs/enroll.tt
  /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs
  
/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs/templates-add-modify.tt
  /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs/clubs.tt
  
/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs/clubs-add-modify.tt
  
/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs/patron-enroll.tt
  
/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs/patron-clubs-tab.tt
  
/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/clubs/club-enrollments.tt

But I do see clubs.pl in the git repository:

  % pwd
  /home/marka/shared/tools/kohaclone
  % ls -laF clubs
  total 36
  drwxr-xr-x  2 marka marka 4096 Jul 19 16:00 ./
  drwxr-xr-x 47 marka marka 4096 Aug  9 11:07 ../
  -rwxr-xr-x  1 marka marka 1267 Jul 19 16:00 club-enrollments.pl*
  -rwxr-xr-x  1 marka marka 3575 Jul 19 16:00 clubs-add-modify.pl*
  -rwxr-xr-x  1 marka marka 1740 Jul 19 16:00 clubs.pl*
  -rwxr-xr-x  1 marka marka 1504 Jul 19 16:00 patron-clubs-tab.pl*
  -rwxr-xr-x  1 marka marka 1358 Jul 19 16:00 patron-enroll.pl*
  -rwxr-xr-x  1 marka marka 5524 Jul 19 16:00 templates-add-modify.pl*
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Searching capability dies every few days - Zebra problem?

[Mark Alexander]

Excerpts from mpw's message of 2017-07-31 06:24:49 -0700:
> I set up Koha a few months ago and we're still learning the system. One
> thing we've noticed that presumably is not normal is that every few days the
> searching capability dies for some reason or other. My guess is that it has
> something to do with Zebra.

It might be this problem:

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

I solved it on my installation using this:

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

Re: [Koha] Status lost for items

[Mark Alexander]

Excerpts from Søren Hovmand's message of 2017-06-22 14:03:15 +:
> To my question - apologies if it should be obvious: Where do I mark
> an item lost? I can find documentation on where it should be (Item
> Statuses/Edit item) but not find the option anywhere in our test
> installation (version 16.05.05.000)

I found this confusing, too.  If you look at the page source for the
"Edit item" page, the field for setting the "lost" status is
marked as invisible.

Instead, when you are looking at the biblio record, click on the "Items" tab
at the left side of the page.  Then you'll see a form where the "Lost status"
can be changed.  This is described here:

http://manual.koha-community.org/16.05/en/catitems.html#itemquickedit
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Slow Koha OPAC login process

[Mark Alexander]

Excerpts from Michael Kuhn's message of 2017-05-09 19:57:51 +0200:
> With my poor Perl knowledge I have now measured the execution time of 
> the various parts of script "opac-user.pl". As I found out everything is 
> always very fast (using less than 1 second execution time) except the 
> very last function in this script which looks as follows:
> 
> output_with_http_headers $cgi, $cookie, $template->output, $content_type;

I am not familiar with this code, but I took a quick look at it just
now.  If I were trying to debug this problem, I would measure the
execution time of the last statement in output_with_http_headers:

print $query->header($options), $data;

If I understand correctly, this print is going to send a big blob of
HTML (preceded by a header) via Apache to the client.  If Apache is
timing out for some reason, perhaps that would cause a big delay in
this print statement.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha Digest, Vol 139, Issue 14

[Mark Alexander]

Excerpts from Ghulam Mustafa Zaman's message of 2017-05-09 07:15:05 -0200:
> i am new koha user and recently i have applied koha software in my college
> library so i need help in few functions like how to create backup of Data .

This should help:

https://wiki.koha-community.org/wiki/Backing_up_Koha

(This is the first hit you get with a Google search for "koha backup").
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha slowed down by Google indexing?!

[Mark Alexander]

Excerpts from Michael Kuhn's message of 2017-05-03 16:14:55 +0200:
>   # ufw status
>   Status: active
> 
>   To Action  From
>   -- --  
>   22/tcp ALLOW   Anywhere
>   80/tcp ALLOW   Anywhere
>   8080/tcp   ALLOW   Anywhere
>   Anywhere   DENY66.249.64.32
> 
> But however this is possible, still Googlebot is crawling and eating 
> CPU!

I haven't used UFW, but I'm looking at the documentation here:

  https://help.ubuntu.com/community/UFW

and it seems that the order of the rules is important.  Quote:

  Once a rule is matched the others will not be evaluated (see manual
  below) so you must put the specific rules first. As rules change you
  may need to delete old rules to ensure that new rules are put in the
  proper order. 

and from the man page:

  Rule ordering is important and the first match wins. Therefore when
  adding rules, add the more specific rules first with more general
  rules later. 

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

Re: [Koha] Koha slowed down by Google indexing?!

[Mark Alexander]

> When I searched for who is 66.249.64.32 I saw this IP addresse belongs
> to Google.

This does seem to be the Google indexer:

  % nslookup 66.249.64.32
  ...
  32.64.249.66.in-addr.arpa name = crawl-66-249-64-32.googlebot.com.

I haven't seen this problem (yet), but perhaps that is because I have
a /usr/share/koha/opac/htdocs/robots.txt containing this:

Crawl-delay: 60

User-agent: *
Disallow: /

User-agent: Googlebot
Disallow: /cgi-bin/koha/opac-search.pl
Disallow: /cgi-bin/koha/opac-showmarc.pl
Disallow: /cgi-bin/koha/opac-detailprint.pl
Disallow: /cgi-bin/koha/opac-ISBDdetail.pl
Disallow: /cgi-bin/koha/opac-MARCdetail.pl
Disallow: /cgi-bin/koha/opac-reserve.pl
Disallow: /cgi-bin/koha/opac-export.pl
Disallow: /cgi-bin/koha/opac-detail.pl
Disallow: /cgi-bin/koha/opac-authoritiesdetail.pl
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] zebra - item-level_itypes errors

[Mark Alexander]

Excerpts from Tom Hanstra's message of 2017-04-19 12:13:30 -0400:
> item-level_itypes set but no itemtype set for item (item#) at
> /usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698

Our installation has item-level_itypes enabled, but all of our item
records (imported from another ILS) have the itype set to a non-NULL
value.  When I manually set the itype of an item to NULL, I see the
above warning in /var/log/koha/INSTANCE/indexer-output.log. 
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Import staged MARC records with ElasticSearch engine

[Mark Alexander]

Excerpts from Abdulsalam Yousef's message of 2017-04-17 11:04:58 +0300:
> - Importing MARC records into catalog form (Manage staged MARC records) in
> staff client GUI using ElasticSearch engine is very slow and accidentally
> stops after importing some hundreds of records, That we may spend 3 days to
> import about 26000 record only, Is that normal? or there are any other
> configurations should be done first with ElasticSearch engine?
> 
> - We are using Koha 16.11.01.

We're not using Elastic Search on our installation, but I have found
that attempting to import our entire catalog of 24000 MARC records
failed due to Koha running out of memory (our system has 2 GB of RAM).
I was forced to split the MARC file into smaller chunks of 2000
records, and import each chunk separately.  A larger chunk might have
worked but I didn't want to take any chances.

I wrote a Ruby script to do the splitting of the MARC records, but
perhaps other tools can do the job (maybe Marcedit, which I haven't used).
The Ruby script is here:

https://github.com/bloovis/marc/blob/master/splitmarc.rb
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Regarding Installation of KOHA in window 1o

[Mark Alexander]

Excerpts from Lalit Thakur's message of 2017-03-27 13:47:13 +0530:
> How can install KOHA Live DVD in window 10. I am trying but I am not
> success. So kindly guide me.

Koha is best installed on Debian 8.  If you really must use Windows,
you could run Debian in a virtual machine; VMware Workstation or
VirtualBox should work for this.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] My Zebra keeps dying

[Mark Alexander]

Excerpts from i.pr...@zigzagee.com's message of 2017-03-13 13:16:19 +:
> Sounds like a sad problem I know but on our Koha test server (16.05) Zebra
>   keeps dying.

This sounds familiar, especially if Zebra is dying in morning.  It might be 
this problem:

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

See this for a possible fix:

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