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

DOM indexing performance
by Fridolin SOMERS 11 Dec '15

11 Dec '15

Hie, We have on a machine big performance issues since indexing was changed from GRS1 to DOM. I have made some benchmarks, looks like indexing time is more than twice longer. When there is a lot of circulation, the indexing of zebraqueue can take more than a minute. We know that this machine is not powerful regarding RAM and disk, but it was enough until now. Does anyone have the same problem ? The point is not to come back to obsolete GRS1, but is there a way to optimize DOM indexing ? My tests shows facets indexing does not change a lot. -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

7 6

Re: [Koha-devel] [Koha] Problem with BarcodeFallbackSearch
by Paul A 10 Dec '15

10 Dec '15

At 10:36 PM 12/9/2015 +0100, someone wrote: >El 09/12/15 a las 22:13, someone else escribiÃ³: > > If this is a desirable feature, a good place to start would be to file a > > bug at http://bugs.koha-community.org. :) That's from the "user" list, and while some of you consider me $whatever, I have concerns regarding the use of the term "bug" that I genuinely believe to be in the best interest of koha-community. "A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." (Wikipedia) 'bugs' -- quantifiable shortcomings in software 'issues' -- potential problems that aren't directly to related code e.g.design decisions 'enhancements' -- ideas that haven't been implemented yet. 'security' -- must be considered separately; breaches are fundamental, not bugs. If backwards correction is not possible, this must be announced. "Security by obscurity" is a fallacy. Suggest[1]: If you are: a) Requesting a new feature (enhancement), or b) Having build problems, or c) Not sure what the behavior should be, or d) Disagreeing with current intended behavior, or e) Not TOTALLY sure that others would agree this is a bug, or f) For any reason at all not sure this should be filed, ...then please post to the dev list first. You'll get a faster response, and others won't be forced to use the bugs.koha database to have the initial real-time conversations. Nothing is lost this way. If it is eventually concluded that it is a bug, then we can still file it later, after the description and reproduction recipe have been honed. Enhancements, improvements and new features: a good starting point is the user list, (IRC?) and possibly the dev list. If there is consensus, this should be filed at ??? <enhancements.koha-community.org> (similar to bugzilla) Best -- Paul [1] loosely based on Apache 2002.

2 1

Proposed "metadata" table for Koha
by David Cook 08 Dec '15

08 Dec '15

Hi all: For those not following along at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662, weve recently started talking about the possibility of adding a metadata table to Koha. The basic schema I have in mind would be something like: metadata.id, metadata.record_id, metadata.scheme, metadata.qualifier, metadata.value. The row would look like: 1, 1, marc21, 001, 123456789 It might also be necessary to store metadata.record_type so as to know where metadata.record_id points. This obviously has a lot of disadvantages redundant data between metadata rows, no database cascades via foreign keys, etc. However, it might be necessary in the short-term as a temporary measure. Of course, adding yet another place to store metadata might not seem like a great idea. We already store metadata in biblioitems.marcxml (and biblioitems.marc), Zebra, and other biblio/biblioitems/items relational database fields. Do we really need a new place to worry about data? That said, if were ever going to move away from MARC as the internal metadata format, we need to start transitioning to something new. Ive noticed this metadata table model in DSpace and other library systems, and it seems to work reasonable well. I dont know if wed break down the whole record into this structure, or if wed just break down certain fields as defined by a configuration file. In the short term, Id like to use something like this to access a records 001 without going to Zebra, which can be slow to update. I need to be able to query a record using the 001 as soon as its added to the database, and I cant necessarily get that from Zebra. I also need to be able to query a record, even if Zebra is down. Failing the metadata table idea, Im not sure how else wed expose the 001 and any number of other fields without using Zebra. We store the 020 and 022 in biblioitems.isbn and biblioitems.issn, but were putting multiple values in a single field, and thats not so great for searching. We might also want to add the 035 to the fields were searching, so I dont think just adding to the biblio or biblioitems tables will really do especially since were trying to move away from MARC. Anyway, please let me know your thoughts. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

3 7

Zebra, Query Parsing, Search, All the things
by David Cook 08 Dec '15

08 Dec '15

Hi all: I was getting 0 results when I should've been getting 78 results with the following query: Host-item:Criminology and criminal justice : an international journal I looked in the Zebra logs, and noticed that it was being transformed into the following: @not @and @attr 1=1033 Criminology @and @and @and @and @and criminal justice = an international journal @attr 1=9011 1 If we decompose the RPN, we'll see that it's basically saying: (Host-item=Crimology and ((((criminal and justice) and = ) and international) and journal )) not Suppression=1 The problem is that "=" is going to return 0 results, so the "and" will always be 0. The way to remedy this problem is to add quotes around our Host-item "value": Host-item:"Criminology and criminal justice an international journal" This will produce the following RPN query, which returns 78 results: @not @attr 1=1033 "Criminology and criminal justice = an international journal" @attr 1=9011 1 As far as I can tell, the = symbol is ignored. You can remove it or substitute another symbol and it'll still return the same number of results. Although it looks like using * for truncation doesn't work in double quotation marks... I suppose that's because it's already part of a term so you can't really translate it into RPN separately. I notice sometimes we strip out double quotation marks from queries and sometimes we add them in. we should probably do something consistent. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

2 1

Start of new release. Some updates.
by Brendan Gallagher 04 Dec '15

04 Dec '15

Now that the release is out, I wanted to give a quick little update for the following release. I will be traveling out of the country from December 1st till December 10th. Really what my plan is that the first few weeks we will not really be pushing new features. We want to concentrate on any bugs that are needed for 3.22.x and master. Kyle will be in the office and handling those needs. He will push and work on those bugs for us. Once I am back and settled in I will concentrate on bugs and new features. I am very open for discussion and I would like to talk with as many of you as I can about the great work that you're doing. Perhaps I will get a chance to speak with each of you about your plans development wise the next few months - so we can have a clear path on timing, getting you help testing your developments, and of course working with the whole team to help QA code. I think as long as we keep our expectations on the same page, we'll have a lot of success helping you meet the goals of a great stable release. Anything that we can do to help promote more initial sign-offs (probably our biggest bottleneck) the better. Let's see what things we can implement to encourage more of us testing the code. I will be encouraging our partner libraries and our staff to be doing as much as we can even with our busy schedules. Be proud! I plan on doing a weekly release newsletter. Thanks and as always don't hesitate to ask some questions. Brendan A. Gallagher

3 2

Release notes
by Frédéric Demians 04 Dec '15

04 Dec '15

Release notes for Koha new versions and maintenance versions are build automatically based on Git repository commits and Bugzilla info. A script named get_bugs.pl from release tools do the job. In the release notes, 4 info from BZ are used: - bug id - summary -- short description of the bug - component: equivalent of Koha module (Acquisition, Web Service, etc.) - severity: critic, normal, new feature, etc. A fifth info can be retrieved in order to describe in detail the bug/feature. This is just the first BZ comment. The first comment can't be changed later in BZ. So very often the 1st comment doesn't describe properly the bug. In order to improve the readability and usefulness of release notes, couldn't we: - Try to normalize and improve the bug summary field when the patch is pushed to master - Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary.

6 6

Re: [Koha-devel] [Koha] "borrowers" permission doesn't allow to see
by BOUIS Sonia 03 Dec '15

03 Dec '15

Hi Jonathan ! Here it is : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15289 Cheers, Sonia Message: 3 Date: Tue, 1 Dec 2015 17:38:19 +0000 From: Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> To: "koha-devel(a)lists.koha-community.org" <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] [Koha] "borrowers" permission doesn't allow to see current loans Message-ID: <CAJzKNY75nG308f_oYen3aYdv87pbrxEw6SAYdvV9q4eeiPty4g(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Sonia, Yes, it's a bug, please open a bug report Cheers, Jonathan 2015-12-01 17:17 GMT+00:00 BOUIS Sonia <sonia.bouis(a)univ-lyon3.fr>: > Hi, > I have a question about the user permission "borrowers". It gives an access to the Details page of a patron. In our previous version, we can see the list of the document checkout in this page. Now, we just have the information 'loading' in the checkout tables, but we can't see documents on loan. (It's the same on the master version). > It's really damageable because we have some students who works in the library who can't do circulation actions, but who should be able to inform patrons to tell them how many books they have, tell them the due date... > > I don't know if this change of behaviour was done on purpose, but for me, it looks like a regression. If everybody is ok with that, I can fill a bug in bugzilla. > > Best regards, > > Sonia BOUIS > > Responsable du Syst?me int?gr? de gestion des biblioth?ques > > bIBLIOTH?QUES UNIVERSITAIRES > Universit? Jean Moulin Lyon 3 > 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe > : +33 (0)4 78 78 79 03 | > http://bu.univ-lyon3.fr<http://bu.univ-lyon3.fr/> > > L'Universit? Jean Moulin est membre fondateur de l'Universit? de Lyon > > _______________________________________________ > Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha ------------------------------ _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ End of Koha-devel Digest, Vol 121, Issue 4 ******************************************

1 0

Inventory/Stocktake Tool UX Improvements
by David Cook 03 Dec '15

03 Dec '15

Hi all: It seems to me that the inventory tool isn't working quite right. at least in 3.14.05. I admit that I haven't checked it in 3.20/3.22/master. I've always found the design of the inventory.pl pages to be rather confusing. Perhaps it's time for a make over? When I read the manual/help and when I look at the page, I figure that it should either generate a shelf list, or upload a barcode list of items to update, or upload a barcode list of items to update and compare it against a shelf list. In the first scenario, no barcode list is provided. So it just generates a shelf list that you can print off to go around the library checking off things manually. In the second scenario, you've scanned maybe 20 barcodes, and you want to update the "date last seen" for those 20 items. So you upload the barcode list, hit submit, and it just updates those 20 items - with no reference at all to a shelf list or the items specified by "Select items you want to check" or "Item statuses". In the third scenario, you've scanned maybe 200 barcodes (e.g. your graphic novel collection), you upload the barcode list, you check "Compare barcode list to results", and click submit. It updates those 200 items AND it shows you a list of items that SHOULD have been scanned too. At the moment, I think the "first scenario" and "third scenario" happen correctly. However, the "second scenario" does not. It basically acts like the "third scenario" except it doesn't give you a list of items that should have been scanned too. although it still looks them up. I recall a few changes have been made in 2015, but I'm not sure if any of them deal with this issue. None of the bug report titles seem to suggest that it has been dealt with. Anyway, I figure that logical change should be made, but maybe also some UX changes so that it's actually fairly intuitive what the hell is going on when people use the inventory tool. I've been working on Koha for 4 years, and every time I look at it, I need to figure it out again. -- Tl;dr. Is anyone attached to the current interface for doing inventories? Are folks in favour of it being changed to be more user-friendly? Are people all right with there being 3 logical scenarios which I've outlined above? (guess you do need to read it after all) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

2 1

"borrowers" permission doesn't allow to see current loans
by BOUIS Sonia 01 Dec '15

01 Dec '15

Hi, I have a question about the user permission "borrowers". It gives an access to the Details page of a patron. In our previous version, we can see the list of the document checkout in this page. Now, we just have the information 'loading' in the checkout tables, but we can't see documents on loan. (It's the same on the master version). It's really damageable because we have some students who works in the library who can't do circulation actions, but who should be able to inform patrons to tell them how many books they have, tell them the due date... I don't know if this change of behaviour was done on purpose, but for me, it looks like a regression. If everybody is ok with that, I can fill a bug in bugzilla. Best regards, Sonia BOUIS Responsable du Système intégré de gestion des bibliothèques bIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 03 | http://bu.univ-lyon3.fr<http://bu.univ-lyon3.fr/> L'Université Jean Moulin est membre fondateur de l'Université de Lyon

2 1

Can the file misc/maintenance/fix_accountlines_date.pl be removed? (Bug 15076)
by Marc Véron 01 Dec '15

01 Dec '15

Hi all Following bug is "In Discussion": Bug 15076 - Remove file misc/maintenance/fix_accountlines_date.pl Is the file still in use by anybody or can it be removed? Thanks for comments on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15076 Marc

1 0