- Koha-devel - lists.koha-community.org

Improving Plack support on the staff client
by Robin Sheat 02 May '14

02 May '14

I've been doing a bit of work lately making patches for the staff client to improve its ability to use Plack without exploding in weird ways. Below list of bugs that I've produced patches for. If anyone is interested in Plack support, it'd be really helpful if you could have a look into these, and perhaps sign some off. Syspref changes weren't appearing: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11998 Fix the web installer: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12023 Improve Koha::Cache to make it more generally useful and Plack-friendly: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12041 Authorised values weren't updating properly: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9967 Framework changes weren't showing up: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11842 MARC staging crashed: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8970 Quote editor wasn't working: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9048 Not really plack, but another bug I found in the quote editor: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12163 (though I see Kyle has signed this one off already, it's a tiny change.) There will probably be more coming. PS: many thanks to Bywater for sponsoring this! -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

2 2

Re: [Koha-devel] Orphaned biblioitems
by Paul A 01 May '14

01 May '14

At 10:31 PM 4/30/2014 -0500, Joy Nelson wrote: >Paul, >I can confirm something along the lines of what you are seeing.Â I've >never been sure if this was cataloger error or Koha error though. What >I've seen is that there is a row (i.e. biblionumber) in the biblio table >but no corresponding biblionumber row in the biblioitems table.Â exists >in biblio but not in biblioitems.Â Sounds like you are saying that you >have a value in biblioitems for a biblionumber but not in the biblio table.Â > >My first instinct is that this would be a delete gone bad.Â or a merge >gone awry.Â Perhaps starting there?Â I'm curious though if the >biblionumber that you are not finding exists in the deleted biblio table??? Thanks for your interest. It is not in either deletedbiblio or deletedbiblioitems: mysql> select * from deletedbiblio where biblionumber=19151; Empty set (0.00 sec) mysql> select * from deletedbiblioitems where biblionumber=19151; Empty set (0.00 sec) but it is in biblio: mysql> select * from biblio where biblionumber=19151; [snip] | 19151 | | Toland, John | The Flying Tigers. | NULL | NULL | 0 | NULL | 1963 | 2013-01-15 16:49:15 | 2013-01-15 | Flying Tigers, Clair Chennault, WWII | +--------------+---------------+--------------+--------------------+----------+-------+--------+-------------+---------------+---------------------+-------------+--------------------------------------+ 1 row in set (0.00 sec) But a staff/admin search /cgi-bin/koha/catalogue/search.pl?q=biblionumber%3D19151 gives "No results found No results match your search for 'biblionumber=19151' in NMA Catalog." I don't think the UTF-8 " = " (equals sign) when it leaves my browser but returned by Koha? Apache? as " %3D " has any relevance. Weird. Best -- Paul >-joy > > >On Wed, Apr 30, 2014 at 7:22 PM, Paul A ><<mailto:paul.a@navalmarinearchive.com>paul.a(a)navalmarinearchive.com> wrote: >At 10:51 AM 5/1/2014 +1200, Robin Sheat wrote: >Paul A schreef op wo 30-04-2014 om 10:03 [-0400]: > > Can anyone please suggest where I could start looking in the code for > > what > > might cause orphaned biblioitems? > >You're going to have to define what an orphaned biblioitem record is, >because that SQL query doesn't seem to do anything that I'd relate to >that term. Do you mean duplicate biblios? > > >Sort of... sorry to be vague, so here's an example, the tail of the query >(simplified to remove the html: > >mysql> SELECT GROUP_CONCAT(biblionumber SEPARATOR ', ') AS BibNums, >Â Â -> EXTRACTVALUE(marcxml,'//controlfield[@tag="001"]') AS Id FROM >biblioitems >Â Â -> GROUP BY Id HAVING count(Id) > 1; >+---------------------+--------------+ >| BibNums Â Â Â Â Â Â | Id Â Â Â Â Â | >+---------------------+--------------+ >[snip] >| 22969, 19151 Â Â Â Â | 8914106 Â Â Â | >+---------------------+--------------+ >31 rows in set (0.89 sec) > >gives me 2 biblio numbers (22969, 19151), both for John Toland's book "The >flying tigers" which has the Library of Congress 001. A search in the >staff page and the OPAC confirm that we only have one -- both show "The >Flying Tigers / (Record no. 22969)" > >If I search for the other number as >cgi-bin/koha/catalogue/<http://search.pl?q=biblionumber=19151>search.pl?q=biblionumber=19151 >in the staff page I get "No results found No results match your search for >'biblionumber=19151' in NMA Catalog." > >BUT... if I specifically go to >/cgi-bin/koha/cataloguing/<http://addbiblio.pl?biblionumber=19151>addbiblio.pl?biblionumber=19151, >I get a biblio that our cataloguers either overwrote or deleted or >whatever... And, because it's not "findable" in the staff page, it cannot >be deleted without direct intervention in the MySQL db. > >I called it an "orphaned biblioitem" because, without looking for that LoC >001 in biblioitems, I would have had no clue that an unused record was >"floating around." > > >All it's doing is finding the first biblionumber of a set where members >have the same 001. This could just be cataloguing the same thing twice, >or records with badly generated 001 entries, or something along those >lines. > > >I'm convinced that your thought "cataloguing the same thing twice" is >correct -- quite often our cataloguers use Z39.50 to update/overwrite a >biblio, but they swear blind that they always delete any previous record >that still appears after re-indexing. > >That's why I'm intrigued about these "orphans" > >Thanks for your interest and best regards -- Paul >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > > > >-- >Joy Nelson >Director of Migrations > ><http://bywatersolutions.com>ByWater Solutions >Support and Consulting for Open Source Software >Office: Fort Worth, TX >Phone/FaxÂ (888)900-8944 ><http://bywatersolutions.com/what-is-koha/>What is Koha? --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

Find the patch!
by Jonathan Druart 01 May '14

01 May '14

Hi developers! I have started to develop a small project. As it is very useful for me, I thought it may be of interest for some of you I named it bz-splitter because the idea is to split patches submitted on bugzilla into hunks, in order to search/browse them via an interface. The actual result is ugly, but functional (I am not a good designer). Sometime it is very difficult to find a patch, because you don't have enough information on what you are searching for. This tool will allow you to find "Which patches modify this file [with which bug status]", "Which patches modify the GetBiblio routine", "What is the bigger patch modifying this file", etc. The link: it is hosted by the Koha community : http://splitter.koha-community.org/ There are 3 views: files, authors and patterns. The 2 first are for browsing patches by filepaths and authors. The last one has only one level and grep a pattern in patches. Note: There is still much to do: improve the UI, add indexes in DB, add status filters for the patterns view + see TODO file. Note on how it works: Only the patches in the 4 statuses Needs Signoff, Signed Off, Failed QA and Passed QA are processed (could be extend later). The code is available on github under the GPLv3 license: https://github.com/joubu/bz-splitter There are only 2 scripts with interesting code: bin/rebuild_data.pl and lib/bzsplitter.pm, the others are tt, css or js files. A very big thank to Chris for his responsiveness for installing and updating the project. Feel free to find another name, submit patches, get feedback, etc. Cheers, Jonathan PS: The feature which is not a bug: when browsing by files, if you unselect some status and don't click on the refresh button, the entries you will expand still take into account the unselected checkboxes http://splitter.koha-community.org/ https://github.com/joubu/bz-splitter

2 1

Koha Plugins
by Wolfram Schneider 01 May '14

01 May '14

I wanted to write a Koha Plugin for meta searching. I used the Kitchen Sink Example from http://bywatersolutions.com/koha-plugins/ as base. So fare, the plugin works well on the staff site (-intra). I can run the configuration template, save values, and read them and run the tool link. Now I want to run the plugin on my opac site (public). But I don't see it here. I read the koha handbook v3.14 but didn't find anything regarding plugins for the opac. I found a hard coded type => "intranet" in lib/Koha/Plugins/Base.pm Did I miss anything? How does I enable a plugin on the opac? Any advice is greatly appreciated! Thanks, Wolfram Schneider -- Wolfram Schneider <wosch(a)FreeBSD.org> http://wolfram.schneider.org

2 1

Orphaned biblioitems
by Paul A 30 Apr '14

30 Apr '14

Can anyone please suggest where I could start looking in the code for what might cause orphaned biblioitems? Running the following query: SELECT GROUP_CONCAT('<a target="_blank" href=\"/ cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=',biblionumber,'\">',biblionumber,'</a>' SEPARATOR ', ') AS BibNums, EXTRACTVALUE(marcxml,'//controlfield[@tag="001"]') AS Id FROM biblioitems GROUP BY Id HAVING count(Id) > 1; finds ~0.1% of our total catalogue with orphans -- often, but not quite always, they are consecutive biblionumbers leading me to think that this happens during cataloguing (but there seems to be no rhyme nor reason as to how it happens, we cannot purposefully duplicate the error.) It's fairly trivial to correct with a " DELETE * FROM biblioitems WHERE biblionumber=123456; " but I'd like to stop it from happening in the first place. Thanks for any suggestions, Paul

4 4

3.16 release calendar
by Galen Charlton 30 Apr '14

30 Apr '14

Hi, I'm setting the following dates for the next steps in the Koha release cycle. Note that date for deadlines should be interpreted to mean that they finish at 23:59 in my time zone, which is presently UTC-08:00. Wednesday, 23 April: alpha release -- I will clear the passed QA queue and roll a tarball. Monday, 28 April: feature freeze -- any new feature or enhancement bug must have reached Passed QA by the end of that day to be considered for inclusion. Note that I may grant the new cataloging editor up to two days of leeway on this deadline. Wednesday, 30 April: beta release -- by the end of the day, I will clear the Passed QA queue and roll a beta release. A soft string freeze will start upon release of the beta; at this point, translators can be confident that there won't be major string changes. Monday, 5 May: at the end of the day, a firm string freeze will beginning. I will not call it a hard freeze, as security bugs and release blockers will trump string stability, but translators can expect that there will be no unnecessary changes. Monday, 19 May: I will cut the release candidate Thursday: 22 May: General release. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 1

Perl 5.18
by Tomas Cohen Arazi 30 Apr '14

30 Apr '14

The latest Ubuntu LTS release includes Perl 5.18. One of the main noticeable consequences of this is that some 5.10 features are now marked as experimental, and hence warnings appear everywhere. One example could be the use of '~~' (C4/Search.pm:536). These warnings can be avoided using the following pragma [1]: no if $] >= 5.018, 'warnings', "experimental::feature_name"; I'd like to know your opinion on how to cope with this. I guess we already had this kind of problems in the past. Regards To+ [1] http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod#Lexical_$__is_now… -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 4333190 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

5 5

March towards 3.16.0 #1
by Galen Charlton 29 Apr '14

29 Apr '14

Hi, I apologize for calling the dev meeting, but not being able to attend it, but I have other unavoidable responsibilities today. Here is a quick update on 3.16.x: - Feature freeze is still end of Monday, 28 April in the PDT time zone. Any patch that reaches passed QA by that point will be considered for 3.16.0. As I mentioned before, I'm granting leeway to the new cataloging editor; I will also grant leeway to multiple transport type enhancements, as there are a number of separate bug reports, some of which have not yet gone through QA. If there are things that you believe are close and worthy of leeway, please reply to this thread. - I will not be cutting an alpha today after all, but will still cut a testing release on 30 April. I may call it alpha or beta depending on how stable it feels to me. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

7 8

git-bz update
by Galen Charlton 26 Apr '14

26 Apr '14

Hi, A couple days ago the latest security release was applied to Koha's Bugzilla installation. The security update included changes to login handling to protect against CSRF attacks; this happened to break git-bz's ability to upload patches and modify bug information. I've pushed a patch that restores git-bz's ability to authenticate to the 'fishsoup' branch of git://git.koha-community.org/git-bz. If you use git-bz, please update now. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

3 4

Release is coming ...
by Fridolin SOMERS 25 Apr '14

25 Apr '14

Hie all, I plan to release the 3.14.06 only next week. I did not spent enough time to backport on stable branch : some vacations, a lot of work, some business trip ... I'm rely sorry and I'd like to spend more time for community. So next week I'm on it. I would like to integrate some important patches like Bug 12134 - Members are restricted even if the debarment is ended - if he reaches to be pushed to master next week. Best regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 0