June 2016 - Koha-bugs - lists.koha-community.org

[Bug 11998] Syspref caching issues
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11998 Jacek Ablewicz <abl(a)biblos.pk.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |16758 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16758 [Bug 16758] Caching issues in scripts running in daemon mode -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11211] Move calculation code out of C4::Calendar
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11211 --- Comment #56 from Karl Holten <kholten(a)switchinc.org> --- Just updating to say that our institutions have interest in this. Bug 8133 is still blocked by this, and when we circulate equipment right now we have to manually set the return to be before the library closes. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9805] Lost items are un-lost if returned, but not if renewed
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 --- Comment #51 from Karl Holten <kholten(a)switchinc.org> --- Any chance we can resolve whatever refactoring or whatever needs to be done for this in some other ticket, as suggested by Jon? There are plenty of items at our consortium that are still marked as "lost" even after someone renewed them, and getting a fix so that this doesn't continue to happen would be very much appreciated. Karl -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12430] Truncation disables relevance ranking when not using QueryParser
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 Mirko Tietgen <mirko(a)abunchofthings.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirko(a)abunchofthings.net --- Comment #11 from Mirko Tietgen <mirko(a)abunchofthings.net> --- (In reply to David Cook from comment #8) > FYI, the issue with st-numeric was fixed in Zebra 2.0.62 > > http://www.indexdata.com/zebra/doc/NEWS Hi David, are there other reasons not to use this patch? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15128] Add ability to limit the number of open purchase suggestions a patron can make
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15128 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch --- Comment #2 from Marc Véron <veron(a)veron.ch> --- Works fine, I like this feature. Maybe the following could be improved: Let's say MaxOpenSuggestions is set to 2. >From OPAC, I add a suggestion 'AAA'. I get the following: ---- Your suggestion has been submitted. There are no pending purchase suggestions. (Hmm, should be one?) New purchase suggestion (Link) ---- I add a 2nd suggestion 'BBB' ---- Your suggestion has been submitted. There are no pending purchase suggestions. (Hmm, should be two?) New purchase suggestion (Link) ---- Clicking the link results in a new screen with the message: "You cannot place any more suggestions" etc. Question: Couldn't the link be replaced by the message (like in the overview page)? That would be a nicer user experience. Then a minor typo on the overview page: The second sentence has no ending punctuation: ---- You have reached your limit of suggestions you can place at this time. Once the library has processed those suggestions you will be able to place more --- Ah, and it would be nice to have the maximum number in the user message. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16753] New: /misc/mod_zebraqueue.pl should allow 'recordDelete'
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16753 Bug ID: 16753 Summary: /misc/mod_zebraqueue.pl should allow 'recordDelete' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz /misc/mod_zebraqueue.pl should the ability to send a 'recordDelete' operation in zebraqueue. My feeling is that mod_zebraqueue.pl should look up the biblio or auth number given; if it doesn't exist, then a 'recordDelete' row should be added to zebraqueue. A --recordDelete option should also be available as an argument to /misc/mod_zebraqueue.pl, in case we need to force a recordDelete for some reason. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14695] Add ability to place multiple item holds on a given record per patron
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #155 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to Benjamin Daeuber from comment #152) > (In reply to Benjamin Daeuber from comment #151) > > > I had not considered that a bug. If you do let me know and I'll change that > > > behavior. > > > > If I allow item > > level holds for certain item types and then have a global preference > > override that, it may be a problem. > > If I *disallowed* item level holds for a certain item type that should say. So, what I had forgotten and had to remind myself was those rules are not meant for the staff side, only for the opac. It has nothing to do with this enhancement. However, I've added a small followup that lets the librarian know if a given item on a record would be forced to be an item level hold or would be disallowed as an item level hold! It seems like a good datum for the librarian to know. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14695] Add ability to place multiple item holds on a given record per patron
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 --- Comment #154 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 52457 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52457&action=ed… Bug 14695 [QA Followup] - Tell librarian if item doesn't allow or forces item level holds in the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10459] borrowers should have a timestamp
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10459 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.maurice(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15108] OAI-PMH provider improvements
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15108 --- Comment #36 from Ere Maijala <ere.maijala(a)helsinki.fi> --- (In reply to Frédéric Demians from comment #35) > > That said, if you think there should be an option to control whether item > > timestamps are taken into account, I can add that. But you're right in that > > if you'd like to only ignore status changes caused by circulation actions, > > that's not possible without changes deeper in the system. > > I suspect that such an option would just add confusion. For scenario (3) > described above, a new patch should be needed. > > But I was just curious whether you was able to measure the number of OAI-PMH > requests to Koha on a large catalog with a lot of circulation. I haven't had a chance to measure this in a live production system. It is estimated that for a large installation we may end up harvesting records in the scale of tens of thousand per day. However, we currently update the VuFind index every half an hour, so the amount of records that change per an update is not as large. When considering scenario (3), please keep in mind that item addition and deletion are also important events. If you don't check item timestamps, you won't get e.g. the locations for any newly added items. -- You are receiving this mail because: You are watching all bug changes.

1 0