- Koha - lists.katipo.co.nz

Email not appearing
by ahmnas 19 Jan '17

19 Jan '17

hi my friends I using and managing koha for sending overdue notice email and checkout and check in but when i go to administrator mail send i don't found the massage that's i send and also patron check email the massage not send to, but when i go to patron notice i check notice tell me sent how solve this i before install koha 3.18.6 on ubuntu 12.04 i want how solve urgent Ahmad Nasser koha system administrator future university in Egypt -- View this message in context: http://koha.1045719.n5.nabble.com/Email-not-appearing-tp5918006.html Sent from the Koha-general mailing list archive at Nabble.com.

1 0

flat fee on notice generation
by Radek Šiman 19 Jan '17

19 Jan '17

Hello everyone, I'd like to ask a question concerning overdue fees. One of our library requests to add a flat fee to common overdue fines. Is it possible to automatically generate a flat fee for the 1st, 2nd and 3rd overdue notices? Let's say a patron owes $5 as a overdue fine of 5 books. The library needs to automatically add to it, for instance, one-off $10 as a flat fee, because the patron has been notified about the items over due. Of course, it's always possible to add such a fee manually, but then the staff has to know which kind of notice has already been generated and the amout must be calculated by humans not mentioning that people can make mistakes. Could anybody recommend a good solution or is it a missing feature right now? Thanks a lot, Radek

2 1

I have problem in koha i think the database for Zebra not updating
by Mutasem Al Shami 19 Jan '17

19 Jan '17

I'm create some of new category (books) in koha and saved it , but when i search it this book the massage appear no result found ,but when i need to barrow the same books, i can barrow from koka admin. how can update database for zebra . Note, i don't have any problem in old book , i can do search and the result appear . The Second Problem, all the user he can access from the own gmail for the college without register in koha all the gmail account coped to koha automatically , but now, all the new user in gmail he can't login and barrow book until i do for him a new user manually from admin . note, i don't have instance the database name koha not like koha_koha. i not find file /etc/cron.d/koha-common . that men this problem. the koha Version 3.12. -- ------------------------------ Disclaimer: This message and its attachment, if any, are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender immediately and delete this message and its attachment, if any, from your system. You should not copy this message or disclose its contents to any other person or use it for any purpose. Statements and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of Al Maarefa College (MCST). All opinions and/or views expressed in this email are solely those of the author and do not necessarily represent those of MCST, MCSTaccepts no liability for damage caused by any virus transmitted by this email. تنويه: هذه الرسالة ومرفقاتها (إن وجدت) تمثل وثيقة سرية قد تحتوي على معلومات تتمتع بحماية وحصانة قانونية. إذا لم تكن الشخص المعني بهذه الرسالة يجب عليك تنبيه المُرسل بخطأ وصولها إليك، وحذف الرسالة ومرفقاتها. ولا يجوز لك نسخ هذه الرسالة أو مرفقاتها أو أي جزء منها، أو البوح بمحتوياتها لأي شخص أو استعمالها لأي غرض. علماً بأن الآراء والإفادات التي تحويها هذه الرسالة تعبر فقط عن رأي المُرسل وليس بالضرورة رأي كلية المعرفة، ولا تتحمل كلية المعرفة أي مسئولية عن الأضرار الناتجة عن أي فيروسات قد يحملها هذا البريد.

2 2

Further adventures with Koha update to 16.xxx
by David Whelchel 19 Jan '17

19 Jan '17

Hi all, It has been several weeks down the road, listing to good music, since my last post and I have made progress in moving from the old Koha Version 16.05.05.000 on Debian 3.2.84-1 x86_64 to Koha 16.11.01 on Debian GNU/Linux 8.6 (jessie), with a quick pass through Koha 16.05.07 on jessie to see if it would correct the errors listed below. No luck, when trying to update to 16.11.01 from either 16.05.05 or 16.05.07 I receive these errors below when going through the Web Installer- Step 3 (Updating database structure). Obviously the 16.0.05 is on a much older code base and OS but the 16.05.07 (no errors here - and I can complete the update and have a functioning system) and the 16.11.01 are on fresh installs of Debian 8.6 and the Koha Common Debian package with an import of the original production database. My questions - 1. are these errors to be expected? 2. Can some of them be ignored? 3. If the error cannot be ignored what is the proper path to move on from here? I am hesitant to make any manual changes to the underlying database as I do not know what down the road implications there might be. Thanks - sorry for the long list of errors but that is what is in red at this step in the process - but I feel that I am almost there. [Sat Jan 14 19:26:46 2017] updatedatabase.pl: DBD::mysql::db do failed: Duplicate column name 'updated_on' [for Statement " [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ALTER TABLE borrowers [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ADD COLUMN updated_on timestamp NULL DEFAULT CURRENT_TIMESTAMP [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ON UPDATE CURRENT_TIMESTAMP [Sat Jan 14 19:26:46 2017] updatedatabase.pl: AFTER privacy_guarantor_checkouts; [Sat Jan 14 19:26:46 2017] updatedatabase.pl: "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 12626. [Sat Jan 14 19:26:46 2017] updatedatabase.pl: DBD::mysql::db do failed: Duplicate column name 'updated_on' [for Statement " [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ALTER TABLE deletedborrowers [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ADD COLUMN updated_on timestamp NULL DEFAULT CURRENT_TIMESTAMP [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ON UPDATE CURRENT_TIMESTAMP [Sat Jan 14 19:26:46 2017] updatedatabase.pl: AFTER privacy_guarantor_checkouts; [Sat Jan 14 19:26:46 2017] updatedatabase.pl: "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 12632. [Sat Jan 14 19:26:46 2017] updatedatabase.pl: DBD::mysql::db do failed: Table 'refund_lost_item_fee_rules' already exists [for Statement " [Sat Jan 14 19:26:46 2017] updatedatabase.pl: CREATE TABLE `refund_lost_item_fee_rules` ( [Sat Jan 14 19:26:46 2017] updatedatabase.pl: `branchcode` varchar(10) NOT NULL default '', [Sat Jan 14 19:26:46 2017] updatedatabase.pl: `refund` tinyint(1) NOT NULL default 0, [Sat Jan 14 19:26:46 2017] updatedatabase.pl: PRIMARY KEY (`branchcode`) [Sat Jan 14 19:26:46 2017] updatedatabase.pl: ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; [Sat Jan 14 19:26:46 2017] updatedatabase.pl: "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 12691. [Sat Jan 14 19:27:36 2017] updatedatabase.pl: DBD::mysql::db do failed: Table 'authorised_value_categories' already exists [for Statement " [Sat Jan 14 19:27:36 2017] updatedatabase.pl: CREATE TABLE authorised_value_categories ( [Sat Jan 14 19:27:36 2017] updatedatabase.pl: category_name VARCHAR(32) NOT NULL, [Sat Jan 14 19:27:36 2017] updatedatabase.pl: primary key (category_name) [Sat Jan 14 19:27:36 2017] updatedatabase.pl: ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; [Sat Jan 14 19:27:36 2017] updatedatabase.pl: "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 13100. [Sat Jan 14 19:27:36 2017] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'BOR_NOTES' for key 'PRIMARY' [for Statement " [Sat Jan 14 19:27:36 2017] updatedatabase.pl: INSERT INTO authorised_value_categories (category_name ) [Sat Jan 14 19:27:36 2017] updatedatabase.pl: SELECT DISTINCT category FROM authorised_values; [Sat Jan 14 19:27:36 2017] updatedatabase.pl: "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 13107. [Sat Jan 14 19:27:37 2017] updatedatabase.pl: DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`koha_koha16`.`#sql-38c_3e`, CONSTRAINT `authorised_values_authorised_values_category` FOREIGN KEY (`category`) REFERENCES `authorised_value_categories` (`category_name`) ON DELETE CASCADE ON ) [for Statement " [Sat Jan 14 19:27:37 2017] updatedatabase.pl: ALTER TABLE authorised_values [Sat Jan 14 19:27:37 2017] updatedatabase.pl: ADD CONSTRAINT `authorised_values_authorised_values_category` FOREIGN KEY (`category`) REFERENCES `authorised_value_categories` (`category_name`) ON DELETE CASCADE ON UPDATE CASCADE; [Sat Jan 14 19:27:37 2017] updatedatabase.pl: "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 13162. [Sat Jan 14 19:29:05 2017] updatedatabase.pl: DBD::mysql::db do failed: Can't DROP 'isbn'; check that column/key exists [for Statement "ALTER TABLE biblioitems DROP INDEX isbn"] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 13684. [Sat Jan 14 19:29:05 2017] updatedatabase.pl: DBD::mysql::db do failed: Can't DROP 'issn'; check that column/key exists [for Statement "ALTER TABLE biblioitems DROP INDEX issn"] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 13685. --Dave ------------------------------------------------------------------------------- David L. Whelchel 725 SE Derby Street Pullman, WA 99163 whelchel(a)pullman.com<mailto:whelchel@pullman.com> http://www.dlwa.com

3 3

Suppressed Bibs Export Issues
by Eric Phetteplace 18 Jan '17

18 Jan '17

Hi list, I'm struggling to find the best way to perform weekly exports of only our *visible* catalog records. We have a discovery layer which takes updated MARC exports, but if a record is suppressed in Koha (either by OpacHiddenItems or 942$n) it still appears in search results, albeit as a broken link. I partially avoid records suppressed at the bib level by excluding bibs where 942$n = 'Y' or '1' in our export report. The report looks at which bibs are new or have been updated since the last time I ran it. There are two problems though: 1) bib records where *all* attached items meet our OpacHiddenItems criteria also need to be suppressed 2) I send newly-deleted record lists too, but not newly-suppressed records (which should be treated as deleted) Sorry if that doesn't make much sense. Basically, I need my current "recently updated bibs" report to skip bibs were all items are hidden in the OPAC*, and I need my "deleted records" report to also include bibs which *used to be visible* but became suppressed since the last update. My SQL knowledge isn't up to either of these tasks. Alternatively, is there some workflow or metadata change we can make to help with this? For instance, what if we stopped using OpacHiddenItems and always suppressed items by setting 942$n? That would fix my first problem, but not the second. My other thought is to use an external database or post-processing script that would let me perform more complex logical checks on records before including them in the update. For instance, a PyMARC script which checks each 952 field on an exported MARC record to see if the record meets our OpacHiddenItems criteria. That's more work than a SQL report but perhaps necessary. * current "updated bibs" report: SELECT biblionumber FROM biblioitems WHERE DATE(timestamp) >= <<update since|date>> -- skip suppressed bibs AND ExtractValue(marcxml, '//datafield[@tag="942"]/subfield[@code="n"]' ) NOT IN ('Y', '1') Best, Eric Phetteplace Systems Librarian California College of the Arts libraries.cca.edu | vault.cca.edu 510.594.3660 2>/dev/null

1 0

New Calendar (17015)
by Philippe Blouin 18 Jan '17

18 Jan '17

Good morning, afternoon, evening, night, Koha Last summer, I brought the issue of the calendar recoding that had been in limbo for a long time, blocking our tentative features like opening hours and fines by minutes. Also among my pet peeves was the fact that calendar calculation where nonapologetically very very (very) slow, slowing the script fines.pl but mostly the simple checkin/checkouts. So Mehdi coded a whole new Calendar (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015) It includes * A new db table storing everyday in the past and future as needed with their respective opening hours. o Perfect calculation for hourly loans o Perfect setup for OPAC display of opening hours * A new intuitive UI o The patches do not remove the old code. It stays in parallel for comparison right now. * A patch replacing all usage of the old calendar by the new one. * A full test suite, replicating all the tests in the previous suite * An speed improvement of 7x for fines.pl * A *_speed improvement of 5-10x_* for checkin with late fees (depending on elapsed time since due date) o Yeah, 4 minutes for 1000 late returns instead of 21 minutes. We know this tool is a huge improvement on the previous code. It also opens a lot more development possibilities for the imagitive Koha developpers. We'll be pushing for it, and I hope it'll get support. We'll fix and improve. Oh, and _*to the testers*_ out there: it's a fun feature. Much more fun to test than some architectural stuff. :) So please come and try it!! Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin(a)inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

1 0

Send email using Microsoft office 365
by ahmnas 17 Jan '17

17 Jan '17

Hi my friends i want to Configure Microsoft office 365 with postfix to send notices from Koha, like gmail, because we change domain from google to Microsoft office. Ahmad Nasser koha system administrator future university in Egypt -- View this message in context: http://koha.1045719.n5.nabble.com/Send-email-using-Microsoft-office-365-tp5… Sent from the Koha-general mailing list archive at Nabble.com.

2 1

Early morning KOHA problem
by Jezzine Library 17 Jan '17

17 Jan '17

Greetings My small library has been happily using KOHA for about 6 months now, but one problem has persisted. First ting is the morning the contents of the catalogue are 'undiscoverable'. They remain so until our IT Guru resets something in the back of the program (which takes about 5 seconds, & one day, he says, even *I* will be able to do it.....) I would much rather have a solution! Even items I catalogue before the reset are undiscoverable once I hit save, even though they turn up quite happily once the reset is done. Our IT Guru is professionally trained and has worked internationally for recognised organisations and this is driving him crazy as he set up KOHA for me is about 30 seconds flat with this as his only problem. He is more than willing to 'talk tech' to anyone who thinks they can help. I have tried logging out properly, not logging out at all, changing username and password, turning the whole machine off and on..... Cheers -- Anne Laguna Librarian Army Museum North Queensland, Jezzine Barracks jezzinelibraryamnq(a)gmail.com Tuesday 9am - 12pm Friday 9am - 12pm

2 1

[Fwd: Koha Image Installation]
by Via Vitae Solutions 17 Jan '17

17 Jan '17

Hi, I am having a problem while installing an image of Koha 16.05.05.000 to another machine. The Problem is while i am writing localhost:<port> or localhost at the address bar to start koha, it is telling me "Unable to connect". Again while i am starting my apache2 service through command line, it is failing, giving an error - " AH0543: apache2: bad user name library-koha Action 'configtest' failed. ". But after adding a new user, my koha is running well and good. But i got this issue in koha 16.05.05.000, not in the older versions. I want to know how can i get rid of this situation. Why am I adding a new user, why the image which i took from the machine is not appropriate? If you can help me out from this situation, then i will be grateful. -- Via Vitae Solutions Kolkata - 700064 India -- Via Vitae Solutions Kolkata - 700064 India

2 1

No Zebra indexing - missing field "biblioitems.marc"
by Michael Kuhn 17 Jan '17

17 Jan '17

Hi I have a new installation of Koha 16.11.01 on Debian GNU/Linux 8, using Koha instance "phsh". I was able to successfully load 76'216 data records in format MARCXML using script "bulkmarcimport.pl". "select count(*) from biblio" shows 76'216 hits in my database. Now I try to index these records in Zebra. To be sure I have restarted the Koha daemon as follows. $ sudo /etc/init.d/koha-common stop $ sudo /etc/init.d/koha-common start Then I try to index my records using the following command: $ sudo koha-rebuild-zebra -f -v phsh But all I get is 76'216 lines like the following: ... .error retrieving biblio 76215 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 713. .error retrieving biblio 76216 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 713. Records exported: 0 Actually absolutely NOTHING is exported and consequently, nothing is indexed by Zebra. I looked into script "rebuild_zebra.pl" at line 713 - some lines before I found the statement "SELECT marc FROM biblioitems WHERE biblionumber = ?" but in the current database schema http://schema.koha-community.org/16_11/tables/biblioitems.html there is no such field "marc" in table "biblioitems"! There was such a field in Koha 16.05 and older versions though. Can anyone please tell me what's wrong here and how to overcome this problem? Best wishes: Michael

3 5