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

[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

[Bug 10873] New: Lots of wasted space in Serial Search Result table
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '14

02 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10873 Bug ID: 10873 Summary: Lots of wasted space in Serial Search Result table Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com /cgi-bin/koha/serials/serials-search.pl?routing=1&searched=1&title_filter= Users with low resolutions or small screens may have an issue where this table exceeds the width of their viewable area. There appears to be a lot of wasted space in the columns, perhaps we could reduce the amount of space allotted to some of those columns and make the experience a little more comfortable for these users. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 6748] New: Add link to fast add framework while circulating, if a barcode is not found
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '14

02 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6748 Bug #: 6748 Summary: Add link to fast add framework while circulating, if a barcode is not found Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Work To Be Done: * Add a button to the "unknown barcode" message in checkout that would bring the user to the Fast Add Framework (for consistency with the rest of Koha) o Automatically populate the barcode with the value scanned o Automatically populate the homebranch and holdingbranch with the currently logged in branch o Automatically populate the non public note to say “return the item to cataloging” * Upon save, the item will automatically be checked out the patron. How to test: * Scan a barcode that is not in your system in the check out screen * Confirm that the behavior follows the above -- 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 12

[Bug 12541] New: Marc modification template - empty field
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '14

02 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12541 Bug ID: 12541 Summary: Marc modification template - empty field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Paola found the following bug on testing bug 11395 comment 33: ERROR on batch_record_modification.pl [I've checked only "Preview MARC"]: case of repeteable subfield [x] in repeteable fields [650]: My biblio record had 3 fields 650, each one had 3 $x: 650 0 ...... _x1-650 x 1 Digital techniques 1 _xfirst 650, second $x _x1-650 x 3 Digital techniques 3 650 0 ........ _x2-650 x 1 Digital techniques 1 _xsecond 650, second $x _x2-650 x 3 Digital techniques 3 650 0 ...... _x3-650 x 1 Digital techniques 1 _xthird 650, second $x _x3-650 x 3 Digital techniques 3 I wanted to delete only the second occurrence of $x, only in the second occurrence of 650 field. So my action was: (A) Delete field 650$x if 650$x matches RegEx m/ ^second 650 / On preview MARC the result is not what I wanted, but: 650 0 ... _x1-650 x 1 Digital techniques 1 _xfirst 650, second $x _x1-650 x 3 Digital techniques 3 650 0 .... 650 0 .... _x3-650 x 1 Digital techniques 1 _xthird 650, second $x _x3-650 x 3 Digital techniques 3 Then I've tried another action, selecting the "first" option: B) Delete 1st field 650$x if 650$x matches RegEx m/ ^second 650 / but the result remained the same as for "All" (A). Neither the 2 negative forms gave me what I wanted: C) Delete field 650$x unless 650$x does not match RegEx m/ ^second 650 / D) Delete 1st field 650$x unless 650$x does not match RegEx m/ ^second 650 / Similar behaviours occurred in Copy, Update and Move cases. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 6858] New: Adds staticfines.pl for static fines processing
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '14

01 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6858 Bug #: 6858 Summary: Adds staticfines.pl for static fines processing Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: matthias.meusburger(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Add a tool to calculate static fine. For example, 7 days left = 1€ fixed fine -- 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 39

[Bug 6809] New: Add branch filter in holds to pull report
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '14

30 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6809 Bug #: 6809 Summary: Add branch filter in holds to pull report Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: savitra.sirohi(a)osslabs.biz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Currently only date filters available, add branch filter. -- 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 8074] New: Holds to pull
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '14

30 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8074 Priority: P5 - low Change sponsored?: --- Bug ID: 8074 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: Holds to pull Severity: enhancement Classification: Unclassified OS: All Reporter: stephane.delaye(a)biblibre.com Hardware: All Status: NEW Version: rel_3_8 Component: Circulation Product: Koha To create the list 'Holds to pull' we must enter the branch and the location at the bottom of the page. It is possible to store in memory the informations(branch, location) that we have chosen; We don't want enter the same informations each time we refreh the screen -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 11391] New: suggestions.suggesteddate has a problematic default value
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '14

30 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11391 Bug ID: 11391 Summary: suggestions.suggesteddate has a problematic default value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 7365 The column suggesteddate in the suggestions table is currently defined as "date NOT NULL default 0". When DBIx::Class translates that PostgreSQLese, it ends up as "date DEFAULT '0000-00-00' NOT NULL". Since 0000-00-00 is not a valid date, DBIC will fail to deploy the suggestions table to a Pg database. Since suggesteddate is supposed to be the date that the suggestion was submitted, CURRENT_DATE is a better default value regardless. -- You are receiving this mail because: You are watching all bug changes.

1 13