October 2012 - Koha-bugs - lists.koha-community.org

[Bug 6617] New: table of contents not printing right if entered right
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '14

22 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6617 Bug #: 6617 Summary: table of contents not printing right if entered right Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4682 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4682 table of contents in 505$a If you're entering the table of contents in a series of $t and $r subfields (in the 505) then it doesn't print the table of contents to the OPAC or staff client right. A formatted table of contents looks like this (505$a): What is a mashup? / Darlene Fichter -- Behind the scenes : some technical details on mashups / Bonaria Biancu -- Making your data available to be mashed up / Ross Singer -- Mashing up with librarian knowledge / Thomas Brevik A slash after the title and before the author and a double dash in between the chapters. See the screenshots to see what I mean. The / should probably be entered by the cataloger, but the double dash should be entered by the template and the contents should show with XSLT turned on even if it's not in the $a only. -- 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 48

[Bug 6918] New: can't place holds on 'on order' items with AllowOnShelfHolds off
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6918 Bug #: 6918 Summary: can't place holds on 'on order' items with AllowOnShelfHolds off Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com I don't think this was always the case (but I might be wrong). If AllowOnShelfHolds is set to 'don't allow' then patrons cannot place holds on items that are marked 'on order' (not for loan=-1). Technically items on order are not on the shelf and should be allowed to be placed on hold. This may require a preference for people to say whether they want to allow holds on 'on order' items and/or what the not for loan value is for 'on order' since there is nothing stopping the user from changing the value from -1 to something else. The easy fix is just to make the system allow holds on items with -1 for notforloan like I think it was before. -- 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 29

[Bug 6374] New: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there)
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6374 Bug #: 6374 Summary: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: januszop(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org In many places the name "size" is used as hash key when the hash is passed to the template system for display. So, for example, since "size" is used as a name of a column of bibioitems table, it appears (or not, depending on if it was defined or not) in elements of SEARCH_RESULTS (in catalogue/search.pl or opac-search.pl) and is passed to the template results.tt/opac-results.tt. Then, in [opac-]results.tt a test is being done: [% IF ( SEARCH_RESULT.size ) %] Now: if "size" was defined, everything is OK and the size will be displayed (e.g. 21 cm), BUT if it was not defined, then a "random" number appears. This is because "size" is one of the virtual methods defined in Template::Toolkit for every data type (cf. http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/VMeth…) So, if "size" was defined by Koha, it will overload the method, but if it was not, then 1) XXX.size exists anyway, 2) the virtual method size() is called -- and it returns the number of elements in the hash or loop etc., depending on what is referred. The number of suspicious similar spots is ca. 20: git grep "IF.*\.size" called in koha-tmpl The issue does not seem to me to be straightforward to resolve, so I am not proposing any patch at the time. Since it seems that in most of the cases it rooted in biblioitems.size column, maybe it would be the simplest to rename that column to 'format' (and make appropriate changes in the code)? Any other ideas? -- 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 27

[Bug 7386] New: Label batches cannot be batch deleted
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '14

18 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7386 Bug #: 7386 Summary: Label batches cannot be batch deleted Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: nflanagan(a)maine.rr.com QAContact: ian.walls(a)bywatersolutions.com Currently label batches must be deleted individually. Selecting several batches and clicking the delete button gives the error: "Please select only one batch todelete." It would be a nice enhancement to be able to delete multiple batches at once. -- 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 8565] New: forgive fines doesn't work
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '14

16 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8565 Priority: P5 - low Change sponsored?: --- Bug ID: 8565 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: forgive fines doesn't work Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha It does not appear that forgive fines on the checkin screen actually forgives anything. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[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 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 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 6070] New: On a new order defined from suggestion some fields were missing.
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6070 Bug #: 6070 Summary: On a new order defined from suggestion some fields were missing. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org (MT #4937) The missing fields : publicationyear, place, collectiontitle. More the layout has been modified. -- 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 54