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

[Bug 8168] New: ersatz CSV header in attachment of overdue notices sent to administrator
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '14

13 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8168 Priority: P5 - low Change sponsored?: --- Bug ID: 8168 Assignee: henridamien(a)koha-fr.org Summary: ersatz CSV header in attachment of overdue notices sent to administrator Severity: minor Classification: Unclassified OS: All Reporter: gmcharlt(a)gmail.com Hardware: All Status: NEW Version: master Component: Notices Product: Koha overdue_notices.pl sends an email to the Koha admin with any notices that should be printed as an attachment. However, if the attachment contains printable notices, rather than CSV, the first line of the attachment still includes a CSV header: title;name;surname;address1;address2;zipcode;city;email;itemcount;itemsinfo;due_date;issue_date There are two problems with this: [1] This header shouldn't be included unless CSV output was specifically requested (by use of the -csv) switch. [2] The header does not respect the delimiter and tabulation system preferences -- it always uses a semicolon. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 9114] New: exported MARC frameworks encoding should be UTF-8
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '14

13 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9114 Bug ID: 9114 Summary: exported MARC frameworks encoding should be UTF-8 Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: gaetan.boisson(a)biblibre.com CC: m.de.rooy(a)rijksmuseum.nl I have noticed on several instances that when exporting a MARC framework it is encoded in ISO-8859-1, which should be UTF-8, the expected encoding for importing frameworks. Also, when chossing SQL as the export format, single quotes are escaped with backslashes, but these backslashes are not removed when importing. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 9366] New: On cataloguing each user can easily display tags or not
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '14

12 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9366 Bug ID: 9366 Summary: On cataloguing each user can easily display tags or not Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com CC: m.de.rooy(a)rijksmuseum.nl If the syspref hide_marc is set to "don't display", tags are not shown by default. The idea is to add a checkbox to hide/show tags directly on the cataloguing page. -- You are receiving this mail because: You are watching all bug changes.

1 49

[Bug 10415] New: Add course reserves to staff client home page
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '14

12 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10415 Bug ID: 10415 Summary: Add course reserves to staff client home page Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org CC: gmcharlt(a)gmail.com If course reserves is an important enough module to list in the global "More" menu then it should follow that it is important enough to include on the staff client home page. The menu choices in the header menu (with the exception of "Cart" mirror the main module links on the staff client home page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 8958] New: Facets are not fully UNIMARC compliant
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '14

11 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8958 Priority: P5 - low Change sponsored?: --- Bug ID: 8958 Assignee: gmcharlt(a)gmail.com Summary: Facets are not fully UNIMARC compliant Severity: normal Classification: Unclassified OS: All Reporter: mathieu.saby(a)univ-rennes2.fr Hardware: All Status: NEW Version: unspecified Component: Searching Product: Koha Hi - The "Place" Facet cannot show up because it is mapped on 651 field instead of 607 field. - Some fields are missing in Unimarc facets (topics : 608, 616 ; authors : 710, 711, 712, 716, 720, 721, 722). - Serials are mapped on 225a. This field is subject to many variants ("Collection Que sais-je?", "Que sais-je", "Que sais je?", etc). Facets would be nicer if we used 410t. Some other fields could be better indexed : 600ab (name/surname) instead of 600a, 601abcdef (hierarchical collectivity or congress) instead of 601a, 604at (author+title) instead of 604a I have made a patch for these issues. I'm planning some other changes regarding Unimarc facets (adding distinct facets for some 6XX, indexing separately all $x subdivisions in su-to, indexing all $y subdivisions in su-geo with 607a, adding language and date facets...), but I will submit these ideas to koha-fr and koha lists first... Regards Mathieu Saby Rennes 2 University -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 8506] New: return date of lost items recorded wrong
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '14

09 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8506 Priority: P5 - low Change sponsored?: --- Bug ID: 8506 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: return date of lost items recorded wrong Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha Patron returned several long overdue/lost items yesterday. They had been due in December of 2011 and were flagged as lost in February 2012. The item history shows they were last seen yesterday--when they were returned, while the checkout history for that items shows that it was returned on 2/17/12 which is actually the day it was flagged as lost. This is misleading because if you look at the item checkout record it shows the items returned when in fact it is not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 9611] New: Changing the password hashing algorithm from MD5 to more secure Bcrypt
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '14

06 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9611 Bug ID: 9611 Summary: Changing the password hashing algorithm from MD5 to more secure Bcrypt Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: srikanth(a)catalyst.net.nz CC: dpavlin(a)rot13.org In the current version of Koha, the passwords are stored as md5 hashes. MD5 hashing has its limitations, changing the hashing method to Bcrypt will improve in more secure password storage. -- You are receiving this mail because: You are watching all bug changes.

1 110

[Bug 10438] New: Packages naming/versioning broken
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10438 Bug ID: 10438 Summary: Packages naming/versioning broken Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: robin(a)catalyst.net.nz Our current packages naming and versioning doesn't support what we claim: if someone wants to maintain an specific version then we'll let him. It is also unnecesarilly complex for the users too. The current schema provides only two stable versions support at a given time, with 'oldstable' and 'stable' dists as a way of specifying that. Not only has that versions limitation (which could be fixed adding something like 'olderoldstable') but is also difficult for the user who has to check whether to change stable to oldstable to avoid unwanted version jump. This makes maintenance difficult even for IT stuff (is not *that* difficult, but is unnecesary). I propose changing the packages naming schema to something like: - Dists: stable (for the stable releases), devel (for the development branches) - Packages naming/version: pick the one VirtualBox uses and have: koha-common-3.8 koha-common-3.10 koha-common-3.12 and so on as packages names. Versioned with their corresponding full version (with minor release number) as it obvoiusly should. I think changing ths should be a minor task, and would make install instructions easier to write, maintain and follow, and would allow us to support more than two stable releases at a time. In a simpler way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8956] New: Split serials enumeration data into separate fields
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8956 Priority: P5 - low Change sponsored?: --- Bug ID: 8956 CC: colin.campbell(a)ptfs-europe.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Split serials enumeration data into separate fields Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Serials Product: Koha Work to be done 1) Add an option 'published_end_date' to the serials table. It will only be used to represent the last issue date in a bound volume. 2) Data clean up: Extract the published dates from the existing enumeration field. Populate serials.publisheddate and serials.published_end_date with this data. 3) Strip the publishing dates from their enumeration fields (probably by simply deleting matched parentheses and everything in between them). 4) In order to break the “Numbered” field into three columns, add X, Y and Z columns to serials, as well as X, Y and Z descriptions columns to the subscription table. 5) Port existing data into these columns. Once all the enumeration fields are of the correct format, e.g., Vol. X No. Y, we can use everything preceding {X} as X_Description, and everything preceding {Y} until } as Y_Description. Another way to look at this is if we split on {?}, we will have all the label fields in order of use. Once we have the label fields, we can parse those out of the enumeration string, and we will have the set of values they represent. 6) Add a calendar widget for published on and expected on (serials-edit.pl). This will require librarians to enter new dates in the accepted format. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 9851] New: way to get full records for purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9851 Bug ID: 9851 Summary: way to get full records for purchase suggestions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com It would be nice if there were a way to get full records for purchase suggestions - a replace via Z39.50 option maybe. Right now most libraries order from a batch given to them from a vendor or from a Z target to get full records, but if they do this then their orders aren't linked to the suggestions. The only way to keep the suggestion linked is to order from it and in essence a brief record. I don't have a good suggestion here, but thought I should share the idea in case someone else has a solution. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1