May 2014 - Koha-bugs - lists.koha-community.org

[Bug 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #28490|0 |1 is obsolete| | --- Comment #60 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 28491 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28491&action=edit Bug 4045 - No check for maximum number of allowed holds. Re-add the system preference maxreserves. All the code using maxreserves is still in place. Though it is not used in the Reserves module, it is used in all the scripts where holds are placed. Also adds a check so that a borrower cannot exceed the maximum number of allowed holds by using the multi-hold feature via the opac. Test Plan: 1) Apply this patch 2) Run updatedatabase 3) Set maxreserves to 3, set opactheme to bootstrap 4) Log into the opac as a patron 5) Place 3 holds 6) Attempt to place a 4th hold 7) Note you get an error message and cannot place a forth hold 8) Delete two of those holds 9) Attempt to place 3 or more holds as a multi-hold 10) You should see a warning that you cannot place this many holds 11) Try to anyway 12) You should see an alert to tell you to reduce the number of holds you are placing. 13) Reduce the number for holds you are placing to 2 14) Your holds should now be placed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #22960|0 |1 is obsolete| | Attachment #22961|0 |1 is obsolete| | Attachment #22962|0 |1 is obsolete| | --- Comment #59 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 28490 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28490&action=edit Bug 4045 - No check for maximum number of allowed holds. Re-add the system preference maxreserves. All the code using maxreserves is still in place. Though it is not used in the Reserves module, it is used in all the scripts where holds are placed. Also adds a check so that a borrower cannot exceed the maximum number of allowed holds by using the multi-hold feature via the opac. Test Plan: 1) Apply this patch 2) Run updatedatabase 3) Set maxreserves to 3 4) Log into the opac as a patron 5) Place 3 holds 6) Attempt to place a 4th hold 7) Note you get an error message and cannot place a forth hold 8) Delete two of those holds 9) Attempt to place 3 or more holds as a multi-hold 10) You should see a warning that you cannot place this many holds 11) Try to anyway 12) You should see an alert to tell you to reduce the number of holds you are placing. 13) Reduce the number for holds you are placing to 2 14) Your holds should now be placed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11794] New: opacSerialDefaultTab being ignored
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11794 Bug ID: 11794 Summary: opacSerialDefaultTab being ignored Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This is true in master and 3.14. If you have opacSerialDefaultTab set to show the subscription tab it still shows the holdings tab as default in ccsr and bootstrap. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 11328] New: local cover images in staff
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11328 Bug ID: 11328 Summary: local cover images in staff Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The local cover images don't show on the staff results. This is what was reported to me: It looks like the staff client search results is using the same localcovers.js that the OPAC search results does however it doesn't work because the two pages are formatted differently. Here is a jquery that solves it for now: $("#searchresults").ready(function(){ $("#searchresults table td").each(function(i){ td = $(this); var tdv = td.find("input[class^='selection']"); var linkv = tdv.attr("value"); var a = $("<a />").attr('href', '/cgi-bin/koha/catalogue/imageviewer.pl?biblionumber=' + $(tdv).attr("value")); var img = $("<img />").attr('src', '/cgi-bin/koha/catalogue/image.pl?thumbnail=1&biblionumber=' + $(tdv).attr("value")) if(linkv){ $(td).append(a); $(a).append(img); } }); }); -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 11802] New: Patron purchase suggestions page requires some corrections
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11802 Bug ID: 11802 Summary: Patron purchase suggestions page requires some corrections Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/members/purchase-suggestions.pl?borrower number=X OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Patrons Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The purchase suggestions page for an individual patron (members/purchase-suggestions.pl) has some errors: - The patron image doesn't appear - The button toolbar markup isn't correct - Unescaped ampersands triggering validation errors -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 11866] New: Staff side course reserves too restrictive
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11866 Bug ID: 11866 Summary: Staff side course reserves too restrictive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org A librarian with no course reserves permissions cannot view course reserves from the staff intranet, yet can from the OPAC. This doesn't make much sense. Librarians should not require any course reserves permissions to view courses and reserves from the staff intranet. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 7234] New: koha-common Debian package should include koha-sites.conf
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7234 Bug #: 7234 Summary: koha-common Debian package should include koha-sites.conf Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: jcamins(a)cpbibliography.com QAContact: ian.walls(a)bywatersolutions.com The koha-common Debian package should provide a sample koha-sites.conf file, so that people can see what the options are. Even better would be if it's possible to have an interactive mode in the package installer so that it requests the settings it needs (or maybe it could look up domain, etc., from somewhere else on the system?). This bug may be invalid. Please mark it as such if it is. -- 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 13

[Bug 11078] New: rebuild_zebra.pl can lose updates due to race condition during full rebuilds
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11078 Bug ID: 11078 Summary: rebuild_zebra.pl can lose updates due to race condition during full rebuilds Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P4 Component: Tools Assignee: dpk(a)randomnotes.org Reporter: dpk(a)randomnotes.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 6435 The race condition exists whether you are doing incremental updates with a periodic cronjob or with the new daemon mode. Suppose you start a full rebuild at time T0 which will take until T20 to extract the records. Suppose also at T10, a biblio or auth is updated and processed through the zebraqueue by T15. In this situation the updated record in zebra will be overwritten when the full rebuild records are uploaded to zebra after T20. We prevent this by only allowing one rebuild_zebra per koha instance to be running at one time. This patch adds flock based locking for rebuild_zebra.pl on a per-instance basis. This prevents races between full rebuilds and background incremental updates from the zebraqueue table in the database. When running in daemon mode (see bug 6435), incremental updates will be skipped while a full rebuild is running, and resume afterwards. A full rebuild or other adhoc request will wait for any previous lock to clear. Tested by flocking the lock file while invoking rebuild_zebra.pl in various modes (daemon, adhoc zebraqueue task, and full rebuild) using flock program I will attach to bug. -- You are receiving this mail because: You are watching all bug changes.

1 88

[Bug 11829] New: JavaScript error on staff client biblio details pages if template variables are undefined
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11829 Bug ID: 11829 Summary: JavaScript error on staff client biblio details pages if template variables are undefined Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org In the JavaScript included in cat-toolbar.inc: var holdcount = [% holdcount %] If [% holdcount %] is undefined that line triggers an error. -- You are receiving this mail because: You are watching all bug changes.

1 19