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

[Bug 9537] New: Add a list of the patches that have been applied to a koha installation
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '15

30 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9537 Bug ID: 9537 Summary: Add a list of the patches that have been applied to a koha installation Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: egpetridis(a)yahoo.com CC: gmcharlt(a)gmail.com I wonder if it would be useful to add a tab in the home, about koha section, displaying a list patches that have been applied to the specific koha installation, similar to the list of pearl modules. This could prove handy when trying to ascertain why a bug that doesn't exist in the main distribution manifests itself in some git derivative or other. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7397] New: Patron search from Checkout tab does 'contains' instead of 'starts_with' search
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '15

30 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7397 Bug #: 7397 Summary: Patron search from Checkout tab does 'contains' instead of 'starts_with' search Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com When searching for a patron using the Checkout tab, instead of the main Patron search, inexact searches (those returning more than 1 hit) do a 'contains' search instead of a 'starts_with' search (as one would expect from the Patron search module's behaviour). The result is many, many more results than one would otherwise expect. The call to Search() in circ/circulation.pl seems to be malformed given the documentation for how C4::Members::Search works. -- 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 5

[Bug 11211] New: Move calculation code out of C4::Calendar
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '15

30 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11211 Bug ID: 11211 Summary: Move calculation code out of C4::Calendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: jweaver(a)bywatersolutions.com Reporter: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Blocks: 8133 Koha::Calendar should contain all of the calendar calculation code, and C4::Calendar should only have admin subs. Created to slim down bug 8133. -- You are receiving this mail because: You are watching all bug changes.

1 74

[Bug 8612] New: System preference to have custom fields in exort csv basket
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '15

27 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8612 Priority: P5 - low Change sponsored?: Sponsored Bug ID: 8612 Assignee: koha-bugs(a)lists.koha-community.org Summary: System preference to have custom fields in exort csv basket Severity: enhancement Classification: Unclassified OS: All Reporter: pelletiermaxime(a)gmail.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha New system preference where you can write the fields you want to have in the "Export this basket as CSV" button in a basket page of the acquisition module. This could be done in better ways, but this is what I came up with, in the time I had. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 10407] New: allow MARCXML records to be imported via Koha's GUI
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '15

27 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10407 Bug ID: 10407 Summary: allow MARCXML records to be imported via Koha's GUI Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com currently, you can only import MARCXML records into Koha using the ./bulkmarcimport.pl tool, from the command-line this bug will attempt to add that functionality to Koha's GUI -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 11358] New: Use Amazon's HTTPS URLs for covers when using HTTPS in Koha.
by bugzilla-daemon＠bugs.koha-community.org 26 Nov '15

26 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11358 Bug ID: 11358 Summary: Use Amazon's HTTPS URLs for covers when using HTTPS in Koha. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fcapovilla(a)live.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 23361 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23361&action=edit Use HTTPS Amazon images when Koha is using HTTPS. This patch checks if the Koha instance is using HTTPS and uses Amazon's HTTPS urls when adding Amazon cover images to the pages. Sponsored-by: CCSR ( http://www.ccsr.qc.ca ) -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 10773] New: Replace item-level codes with names/descriptions for Label Printing
by bugzilla-daemon＠bugs.koha-community.org 26 Nov '15

26 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10773 Bug ID: 10773 Summary: Replace item-level codes with names/descriptions for Label Printing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label printing Assignee: cnighswonger(a)foundations.edu Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, if you include "ccode","homebranch","holdingbranch","location", or "permanent_location" when printing labels, you'll end up with a code rather than a descriptive name/label. While I don't know how often you would necessarily use all of these, I have had a request come in for a label (instead of a code) for "homebranch" as they want their labels to include their library name. Makes sense to me. We already do it with item type. Collection code might be another one or location/permanent_location, depending on how they work their collections. "Holdingbranch" probably never but best perhaps to throw it in for good measure... -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 10827] New: List of holds does not update correctly
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '15

25 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10827 Bug ID: 10827 Summary: List of holds does not update correctly Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: costalc(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an item has many patron's holds and it is checked-in, the first priority patron hold in the list of holds is set as "waiting". Then when this hold expires o is cancelled the hole list of holds doesn't update: the next patron in the list of holds "keeps on hold" but not "waiting" and no email is inserted in the message queue table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 11360] New: Disable barcode field and submit button when a hold is found
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '15

25 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11360 Bug ID: 11360 Summary: Disable barcode field and submit button when a hold is found Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment when scanning in returns, it can be easy to miss a hold trap due to the fact that the barcode and submit are still active and the barcode field is focused on. A librarian who is focused on scanning can easily scan another item and pass over the form, which is equivalent to clicking the "ignore" button. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 12556] New: SelfCheck machine starts the hold instantly with an email sent out
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '15

25 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12556 Bug ID: 12556 Summary: SelfCheck machine starts the hold instantly with an email sent out Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.field(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Currently when a reserved book is returned on a SelfCheck machine the hold starts the hold instantly with an email sent out. It would be preferable if the hold started once it had been taken out of the SelfCheck bins and checked in by reservations staff at the counter. Current suggestion: Possible time delay on the message - may help if after 8 at night and 9 the following morning if delayed until following morning still a workaround if looked at account on OPAC they would see a hold e.g. so theoretically it could still be in the bin - it is difficult to find a correct time delay because of the number of variables - a bit more of a task to put in functionality change Possible Ideal Process: Requested item is returned via SelfService machine - for the patron the process remains the same (they are directed to put it in the RED slot) Instead of an email being sent immediately at that point to the patron next in line for the request, the item would have a new circulation status e.g. ‘In SelfService’ this removes the item from the patron’s record but does not trigger the next hold until it is checked-in by a member of the library, at which point the item moves onto the next circulation status that it would have had before going into ‘In SelfService’ (e.g. ‘On hold’ or ‘in transit’ etc.) There could be different variations of this process based on what is easiest to incorporate into Koha e.g. the item could possibly go into a transit status to a new Shelving Location or Branch - again ‘SelfService etc.’ - before returning to the correct next circulation status as described before - once it is checked-in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3