August 2012 - Koha-bugs - lists.koha-community.org

[Bug 8233] New: New search engine layer - introduce solr without breaking anything else
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '14

07 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8233 Priority: P5 - low Change sponsored?: --- Bug ID: 8233 Assignee: gmcharlt(a)gmail.com Summary: New search engine layer - introduce solr without breaking anything else Severity: enhancement Classification: Unclassified OS: All Reporter: claire.hernandez(a)biblibre.com Hardware: All Status: NEW Version: unspecified Component: Searching Product: Koha Introduce the Koha::SearchEngine work (hackfest12 kohacon12) and a first poc with Solr. The goal is to break nothing and provide a first work wich will be enhance. Please use the wiki or koha-devel for discussion: http://wiki.koha-community.org/wiki/SearchEngine_Layer_RFC -- You are receiving this mail because: You are watching all bug changes.

1 62

[Bug 8567] New: Set output directory for fines.pl in cron config created by the packages
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '14

04 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8567 Priority: P5 - low Change sponsored?: --- Bug ID: 8567 CC: robin(a)catalyst.net.nz Assignee: koha-bugs(a)lists.koha-community.org Summary: Set output directory for fines.pl in cron config created by the packages Severity: enhancement Classification: Unclassified OS: All Reporter: magnus(a)enger.priv.no Hardware: All Status: NEW Version: master Component: Packaging Product: Koha When the Debian packages are installed, they create a /etc/cron.daily/koha-common config based on the template in debian/koha-common.cron.daily. This results in the following command for fines.pl: koha-foreach --enabled /usr/share/koha/bin/cronjobs/fines.pl and this results in this script writing daily log files to /tmp, which is less than ideal. Now, fines.pl has an option --out to specify where the logs are saved, so we could change the cron config to something like this: koha-foreach --enabled /usr/share/koha/bin/cronjobs/fines.pl --out /var/log/koha/__instancename__ Caveat: This depends on Bug 8566 being implemented first! (Because without it there is no way for koha-foreach to use directories named after the instances.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 7441] New: search results showing wrong branch?
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '14

03 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7441 Bug #: 7441 Summary: search results showing wrong branch? Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com When you search in the OPAC it shows you the HOME branch on the location in XSLT (see here: http://screencast.com/t/m870Mr8Wm) but if you click through to the detail page it shows you the CURRENT BRANCH in the holdings table which is very confusing to patrons. I don't know what's the right solution - home or holding branch, but they should be the same in both places for the patron's sake. If you do the same search in the staff client you see the right branch info on the search results and on the detail page. Nicole -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 83

[Bug 8466] New: Holds on MARC records with no item causes silent error in koha-error_log
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '14

03 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8466 Priority: P5 - low Change sponsored?: --- Bug ID: 8466 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: Holds on MARC records with no item causes silent error in koha-error_log Severity: minor Classification: Unclassified OS: All Reporter: kolpen(a)o2.pl Hardware: All Status: NEW Version: rel_3_6 Component: Cataloging Product: Koha Created attachment 10931 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10931&action=edit proposed (two) patches While cataloging, viewing MARC details of record that hasn't items yet, a silent error occurs in koha-error_log when a librarian clicks on the "Holds" tab. The error messages are like that: request.pl: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 3 at /usr/share/koha/lib/C4/Koha.pm line 811., request.pl: DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /usr/share/koha/lib/C4/Koha.pm line 814., The reason is an empty items value in dynamically build query in procedures: - Module: Items.pm, procedure: GetItemInfosOf - Module: Biblio.pm, procedure: GetBiblioItemInfosOf Proposed patch refers to the version 3.6.4 The bug occurs also in later Koha versions (ie. 3.6.6, 3.8) and the same patches should be implemented there (it is only one line add), respectively: Module: Items.pm - line 1064 in version 3.6.6; line 1069 in version 3.8 Module: Biblio.pm - line 1014 in version 3.6.6; line 1026 in version 3.8 -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 8566] New: Enable koha-foreach to insert the instancename into commands
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '14

02 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8566 Priority: P5 - low Change sponsored?: --- Bug ID: 8566 CC: robin(a)catalyst.net.nz Assignee: koha-bugs(a)lists.koha-community.org Summary: Enable koha-foreach to insert the instancename into commands Severity: enhancement Classification: Unclassified OS: All Reporter: magnus(a)enger.priv.no Hardware: All Status: NEW Version: master Component: Packaging Product: Koha The synopsis for koha-foreach looks like this: koha-foreach [--enabled] [--email|--noemail] [command] It is used e.g. in cron configs, like this: koha-foreach --enabled /usr/share/koha/bin/cronjobs/fines.pl It would be very useful if we could provide a placeholder in the command, which could then be replaced with the name of the current instance. Then we could do e.g.: koha-foreach --enabled /usr/share/koha/bin/cronjobs/fines.pl --out /var/log/koha/__instancename__ and have fines.pl use the right directory for each instance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 7518] New: searches with quotation marks don't work
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '14

02 Jul '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7518 Bug #: 7518 Summary: searches with quotation marks don't work Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: melia(a)bywatersolutions.com QAContact: koha.sekjal(a)gmail.com A search term without quotation marks returns the expected results. The same search term with quotation marks returns no results. I expected Koha to ignore the quotation marks and return results anyway... -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 56

[Bug 8500] New: koha-remove needs a --force switch
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '14

27 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8500 Priority: P5 - low Change sponsored?: --- Bug ID: 8500 CC: robin(a)catalyst.net.nz Assignee: koha-bugs(a)lists.koha-community.org Summary: koha-remove needs a --force switch Severity: enhancement Classification: Unclassified OS: All Reporter: cnighswonger(a)foundations.edu Hardware: All Status: NEW Version: rel_3_8 Component: Packaging Product: Koha When running koha-remove, if the db for the instance being removed has been previously dropped, koha-remove throws an error and exits. We should add a --force switch so that koha-remove can be made to continue with the cleanup regardless of what errors it encounters. Of course appropriate warnings should be announced. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8560] New: renewing lost items
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '14

25 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8560 Priority: P5 - low Change sponsored?: --- Bug ID: 8560 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: renewing lost items Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha I got this report from a library: When items age to long overdue lost, they assess a fee equivalent to the replacement price of the item. That makes sense. When those items are checked in, the fee is removed and the titles no longer display as checked out. The overdue does remain in the patron's history under fines. That also makes sense. However, if we renew one of those items, it assigns a new due date, but does not remove the fee or the long overdue lost designation. And, if we take payment on the item, it balances out the fee, reducing the amount due accordingly, but the title continues to display in the list of items out as long overdue lost. The result of this is that our staff members continue to mention these overdue items to the patron even after they've been taken care of. Other categories of lost - those that are manually set - remove the title from the list of items out. Renewing an item should also remove the fees and the long overdue designation. And paying for the item should remove it from items out and show it only in payment history. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7058] New: GetMemberDetails must die!
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '14

25 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7058 Bug #: 7058 Summary: GetMemberDetails must die! Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org The GetMemberDetails subroutine is insanely inefficient, and is used throughout Koha's code. In many cases, GetMember is more than sufficient (please see my rant on bug 5179). This report shall serve as the meta-report for all attempts to eliminate unnecessary calls get GetMemberDetails. Please file separate bug reports for specific instances, and list them as "blocking" this report. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 5

[Bug 5179] New: GetMember and GetMemberDetails should be combined
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '14

25 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5179 Summary: GetMember and GetMemberDetails should be combined Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In Members.pm, GetMember and GetMemberDetails do almost the same thing. This common behaviour should be combined so that changes to this kind of thing don't have to happen in multiple places. Aiming for 3.4. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 2