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

[Bug 9322] New: If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 Bug ID: 9322 Summary: If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz CC: gmcharlt(a)gmail.com To replicate: * get an item's barcode * go to circulation -> transfers * select a branch to transfer to * put in your barcode * submit the transfer * select a different branch to transfer to * (I don't know why you would do this, but) put your same barcode in again * submit the transfer * select a third branch to transfer to * (again, I don't know why you would do this, but) put your same barcode in again * submit the transfer A query against the database will show 3 transfers: select * from branchtransfers; +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 14:31:14 | CPL | | FFL | NULL | | 989 | 2012-12-27 14:31:20 | FFL | | FRL | NULL | | 989 | 2012-12-27 14:34:22 | FRL | | CPL | NULL | You can see it's done something kind of smart, by putting the 2nd transfer to go from the destination of the first transfer. Makes good sense. What doesn't make such good sense is that when you complete the first transfer, the following happens: select * from branchtransfers; +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 14:31:14 | CPL | 2012-12-27 14:34:36 | FFL | NULL | | 989 | 2012-12-27 14:31:20 | FFL | 2012-12-27 14:34:36 | FRL | NULL | | 989 | 2012-12-27 14:34:22 | FRL | 2012-12-27 14:34:36 | CPL | NULL | +------------+---------------------+------------+---------------------+----------+---------------+ All three transfers are received when the first one is. The other two don't trigger. It's like they never existed. I think this also happens when you have a reserve triggered transit in addition to a circ/branchtransfers.pl transit. This is the cause of the occasional "Item on hold for <patron>, item is already waiting" messages when you would normally be expecting a "Confirm hold for <patron>" message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 10655] New: Include list of holds on circ slip or offer separate printing option
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10655 Bug ID: 10655 Summary: Include list of holds on circ slip or offer separate printing option 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com One of our libraries asked for an option to print a list of open holds for the patron. As far as I can tell it's currently not possible to include a list of holds on the available circulation slips and there is no separate option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9723] New: Hourly loans don't show time due in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9723 Bug ID: 9723 Summary: Hourly loans don't show time due in OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com The time an item is due does not display on the patron's record in the OPAC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 7712] New: a single holds report
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7712 Priority: P5 - low Change sponsored?: --- Bug ID: 7712 CC: gmcharlt(a)gmail.com Assignee: koha.sekjal(a)gmail.com Summary: a single holds report QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Koha currently has two holds reports: Holds to Pull and Holds Queue. The difference between them is often unclear and confusing. The system shall provide a single report page to detail which materials should be pulled from a branches shelves, and where these items should be sent. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 7711] New: clear holds statuses and workflow
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7711 Priority: P5 - low Change sponsored?: --- Bug ID: 7711 CC: gmcharlt(a)gmail.com Assignee: koha.sekjal(a)gmail.com Summary: clear holds statuses and workflow QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Created attachment 8197 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8197&action=edit Status Workflow Mapping Clear statuses For each hold in the system, there should be a clear, single status to describe it's current state. These statuses should include: Waiting (in holds queue) Ready to pull Pulled and awaiting pickup Filled Expired Long waiting In transit Suspended Canceled Since these statuses have concrete system states attached to them, they must be hard coded into the system. The use of an Authorized Value list would not be sufficient. Status Workflow Not every status should be reachable from every other status. Attached is a mapping of which statuses a hold shall be able change between. O with a green background indicates possible, while X with a red background indicates impossible. Grey cells are for self-references. [Please see attachment.] Holds shall be considered 'waiting in queue' until they reach the top position of the queue, at which time they change to 'ready to pull'. While in the queue, they can expire, be suspended, or be canceled. Once the hold is ready to pull, the next natural next step for the hold to transition to the “Pulled” state, where it awaits being picked up by the patron. Since this status just means the hold is at the top of the queue, if the queue is rearranged, the status of the hold could go back to 'Waiting in queue'. The hold can also expire, be suspended or be canceled. After the hold is pulled, it should either be picked up by the patron and marked as 'filled', or put 'in transit' to the pick up location. It can also still expire or be canceled. If the hold waits to be picked up for more than appropriate MaxReservePickupDelay circ rule, it will be marked as 'long waiting'. If a hold needs to be transferred to another branch, the status shall go from 'Ready to Pull' to 'In Transit'. Once the item arrives at it's destination and is received, it shall be marked as 'Pulled and ready for pickup' Expired, Suspended and Canceled holds can be brought back into the queue. “Filled” is a terminal status; the hold record can now be archived. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 12314] New: "Pay an amount toward all fines" does not save the note
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12314 Bug ID: 12314 Summary: "Pay an amount toward all fines" does not save the note Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Pay Fines -> Pay amount, the note is not saved anywhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 12071] New: javascript broken for a search with double quotes
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12071 Bug ID: 12071 Summary: javascript broken for a search with double quotes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In staff interface, when performing a simple search with a double quote (ie "histoire algerie"), the javascript is broken in results page because of : function GetZ3950Terms(){ var strQuery="&frameworkcode="; strQuery += "&" + "title" + "=" + ""histoire%20algerie""; Double quotes are not URI-escaped. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 11756] New: Hold ratios report sorting incorrectly
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11756 Bug ID: 11756 Summary: Hold ratios report sorting incorrectly Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bartonski(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 25237 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25237&action=edit Screenshot of Hold ratios report at the reporting library In Home › Circulation › Hold ratios, When rows are sorted by the hold count, the sort is alphabetic rather than numeric. To replicate: Check out 3 titles, A, B, C, each having a single item. (The Holds Ratio report only shows titles with 3 or more holds per title) Place 3 hold on title A Place 4 holds on title B Place 10 holds in title C Bring up Hold Ratios report, and sort by the 'Holds' column When ascending, they will sort 10 | C 3 | A 4 | B They should sort 3 | A 4 | B 10 | C -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 6891] New: LDIF interoperability - a proposal
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6891 Bug #: 6891 Summary: LDIF interoperability - a proposal Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: xan(a)biblionix.com QAContact: koha-bugs(a)lists.koha-community.org Hello Koha Community, I'm Xan Charbonnet with Biblionix. We're a small company that provides a hosted ILS, Apollo, to small and medium-sized public libraries in the US. We're not open-source, but we do strongly believe in open interchange: library data belongs to libraries, and shouldn't be used as a hostage to keep libraries chained to their automation systems. Far too many systems do treat their customers this way. There are even Koha consortia which are charging their librarians multi-thousand dollar extraction fees just to get their own data out! We've developed what we call LDIF (library data interchange format), which is a W3C XML Schema that defines a way for library data to be stored and exchanged in a vendor-independent manner. We believe this is an important capability which has been missing in the library world. Any Apollo library is able to generate an LDIF file at any time, and download (practically) everything that Apollo knows about their library in a single, well-defined file, complete with the schema. Ideally, that file would be easily importable into any other ILS. Part of making LDIF "real", of course, is engaging other ILS vendors. The Koha Community seemed like the place to start. Is there anyone working on the Koha project who would have an interest in developing support for this fledgling standard? And of course, in working with you, there will likely be changes to be made to LDIF, which will make it better for everyone. LDIF Schema: http://www.biblionix.com/ldif.xsd Example library export (I recommend that you download this rather than view it in your browser; it's a 4MB XML file): http://www.biblionix.com/demolibrary_2011-09-20.xml -- 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 26

[Bug 7611] New: Show the NOT_LOAN authorised values for item status in XSLT OPAC search results.
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '14

07 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7611 Bug #: 7611 Summary: Show the NOT_LOAN authorised values for item status in XSLT OPAC search results. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: fcapovilla(a)live.ca QAContact: koha.sekjal(a)gmail.com Created attachment 7905 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7905 XSLT Results template improvement : Use the NOT_LOAN authorised values Improvement : Use the NOT_LOAN authorised values when showing items status in the OPAC search results. Before this patch, these items were only considered as "unavailable". Note : This patch only affects the OPAC XSLT search results template for MARC21 records. This patch was not tested on UNIMARC or NORMARC records. I won't be able to support these formats, so I'm hoping someone could do the same for these other record formats. Patch attached. -- 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 7