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

Hide records on Leader 05 = d in OPAC
by David Cook 18 Jan '16

18 Jan '16

Hi all: Recently, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 was pushed to master. It adds a cronjob which deletes bibliographic records, if their LDR05 is "d" (ie status deleted). While I'm all for that, I'm thinking that it would also be a good idea to hide these records with LDR05 "d" in the OPAC before the cronjob is run. We can't necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldn't we be hiding these records from the OPAC as soon as they're marked as "deleted"? I've opened a bug for this purpose: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 It should be a pretty easy change, especially when using special attribute @attr 14=1 to avoid past OpacSuppression problems, but I thought I'd ask folk if it's something they'd be interested in. We'd probably still want to see these records in the Staff Client, as we want to be able to find all records in the database in the Staff Client. I admit that I have a special interest in this where I might be overlaying existing records using a mostly empty skeleton record generated from an OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesn't send metadata for deleted records). I'd match the existing record in Koha using the identifier, and then set LDR05 to "d" in accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users don't see this skeleton record. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

5 11

Call for news: January 2016 Newsletter
by kohanews 16 Jan '16

16 Jan '16

Fellow Koha users ~ I'm collecting news for the January newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events -- **** one month back is the cut-off ***. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Call for development news: January 2016 Newsletter
by kohanews 15 Jan '16

15 Jan '16

Let the community hear what cool things you're working on! Send me some bugs that need testing, sign-offs and user feedback. Suggestions welcome! k o h a news AT gmail dot com Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Merge borrowers and deletedborrowers tables
by Jonathan Druart 15 Jan '16

15 Jan '16

Hi devs, I am sure the community has already discussed about that: I am wondering why do we have a borrowers and a deletedborrowers tables when a "delete" flag in the borrowers table could do the trick. I am sure it's a matter of optimizing the sql queries, but did someone already compare on a descent database? It would help a lot to have the foreign keys set on other tables, to display the data if the library wants to displayed them. See bugs 13534 13668 14849 Doing this way, we make the DB structure consistent, but we will lost info. Cheers, Jonathan

5 5

RFC: Circulation Rules Interface and Backend Revamp RFC
by Jesse 13 Jan '16

13 Jan '16

The backend and frontend of the circulation/policy rules in Koha have been extended and stretched to the point where they cause a fair amount of issues and frustration. Many librarians and developers are uncertain when default rules are applied, and the very large number of possible settings makes the interface and backend unwieldy. Full details for our intended solution can be found at the link at the bottom of this email, but here's the gist: Instead of having one database row with all settings for a given library/category/itemtype, allow each setting (checkout length, fine amount, holds allowed, etc.) to be specified separately. Rework the interface to more clearly show the specificity of default/specific rules, and allow for this new database model. Accomplish the above incrementally by gradually changing APIs. http://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend… Any and all comments are appreciated. Development on this project has been fully sponsored, and we are looking to start work later this year. -- Jesse Weaver

2 2

Reminder: General IRC meeting 13 January 2016
by Katrin Fischer 13 Jan '16

13 Jan '16

Hi all, just a quick reminder of the Koha General IRC meeting on 13 January 2016 at 20:00 UTC http://wiki.koha-community.org/wiki/General_IRC_meeting_13_January_2016 Hope to see you there :) Katrin

1 0

Playing with NYTProf
by Jonathan Druart 12 Jan '16

12 Jan '16

Hi devs, I have played with NYTProf at the end of the last week, here is my loosely structured notes: https://joubu.github.io/koha/nytprof/dbic/index.html I have not found big things to implement in order to improve the speed but I am wondering if there is not something wrong with the queries cache (Search in the page for "Update:") Hope to get some feedbacks. Cheers, Jonathan PS: If someone has a better idea to share the profiles, I am open-minded.

3 3

Prevent normalization during matching/import process
by David Cook 11 Jan '16

11 Jan '16

Hi all: I've opened a bug for preventing normalization during the matching/import process: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 I was trying to use a URL field as a matchpoint, and it was going horribly badly. 1) By default, punctuation is stripped, leading/trailing spaces are trimmed, and more than one space is condensed down to one space. This makes a URL into a string without any spaces or punctuation. 2) So, I had to add "Identifier-other:u" to biblio-zebra-indexdefs.xsl but I couldn't access it until I tried "id-other,st-urx" as my match point. The st-urx is necessary to make it use the ":u" register. 3) I also added some code to C4/Matcher.pm so that a match point normalizer of "None" would disable the normalization from #1. 4) I also plan to add a flag to C4::Search::SimpleSearch to disable the s/:/=/g normalization since that also destroys the URL in the query and makes it fail to match. I've only tested this so far with CHR but it works well. I'll probably look at ICU tomorrow. I'm sure there are probably other cases than just URLs where we will want to skip the default normalizing when doing matching. or normalize it in a way that accords with the way Zebra normalizes the data in records. For instance, Zebra will replace punctuation with a space for "phrase" indexes rather than just stripping it out and leaving nothing behind. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

1 0

Koha Hackfest in Berlin?
by Mirko Tietgen 07 Jan '16

07 Jan '16

Hello there, European (and other) Koha devs, I am considering hosting a Koha hackfest in Berlin/ Germany next year. It is not supposed to be a counter event to the Hackfest in Marseille nor the Kohacon, but an additional option to meet and work together. It could maybe take place July 2016 (very preliminary date for very preliminary planning), maybe 3 days or the whole week. Before I spend more time fantasizing about it, I'd like your opinion… - do you think it is a good idea (and you would consider joining)? - do you think it is a good idea (but you know you won't join)? - do you think it is not a good idea (given there is a Hackfest in Marseille and Kohacon already, or for other reasons)? - do you think you would have to decide between Berlin and Marseille? - do you think something completely different? No hard feelings if you say Kohacon + Marseille is enough, that would be very valuable feedback. For obvious reasons I would love to hear opinions from Europe (positive or negative), but if coming to Berlin is an option for people from more distant places, I'd love to hear that too. Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

7 14

API keys
by David Cook 07 Jan '16

07 Jan '16

Hey all: What do people think about having keys for Koha APIs? Someone would register a key in Koha and give that key to the developer, the developer puts it in their app configuration, and they're good to go. One advantage would be that apps utilizing web services wouldn't actually have access to Koha itself - just to the APIs associated with the API key. By that same token, a Koha administrator could easily revoke access to an API if necessary for whatever reason. I'm sure there are other advantages as well. I was thinking a single API key could replace the username/password pair, but you still might want a client_id and an API key, so you're still managing two fields in your configuration. Anyway, just a thought. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

2 2