February 2015 - Koha-bugs - lists.koha-community.org

[Bug 9139] New: Sending empty vendor or biblio when adding subscriptions gives error
by bugzilla-daemon＠bugs.koha-community.org 18 May '15

18 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9139 Bug ID: 9139 Summary: Sending empty vendor or biblio when adding subscriptions gives error Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/serials/subscription-add.pl OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: colin.campbell(a)ptfs-europe.com I can only reproduce this in Firefox, not in Chromium. To reproduce: - Add a new subscription - Put cursor in first field for 'Vendor' or 'Biblio' and hit enter - Perl error page is shown: No record at /home/katrin/kohaclone/C4/Serials.pm line 1382 Sending an empty field should open the search pop up and not give a perl error message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 11576] New: Untranslatable "manage" in serials-collection
by bugzilla-daemon＠bugs.koha-community.org 18 May '15

18 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11576 Bug ID: 11576 Summary: Untranslatable "manage" in serials-collection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr PrepareSerialsData() in C4/Serials.pm has a hard-coded "manage", which is shown to the user in serials-collection -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 10335] New: UNIMARC authorities search doesn't display properly information on parallel form
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10335 Bug ID: 10335 Summary: UNIMARC authorities search doesn't display properly information on parallel form Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: januszop(a)gmail.com UNIMARC authorities can contain translated headings. The language is coded in $8 subfield: "Subfield $8 contains 6 character positions (designated as $8/0, 8/1, etc.) The first group of three characters specifies the language of catalogue into which the heading in the field is designed to fit; the second group of three characters specifies the language of the base heading. The language codes are listed in the ISO 639-2 standard and in Appendix A of the UNIMARC Manual - Bibliographic Format." (cf. UNIMARC manual : authorities format. -- 2nd rev. and enl. ed. -- München : Saur, 2001, p. 66) I.e. it is the second triple designates the language of in which the actual parallel form is entered. Currently the information is displayed wrongly. To reproduce: 1) Create an authority record with main heading (100) in Latin script (e.g. Oppenheimer, Aharon -- subfields $a and $b) and parallel form (700) in Hebrew (אופנהיימר, אהרן -- subfields $a and $b). Mark it correctly in $8 with freheb (or engheb if you like); 2) reindex and search; 3) you will see: Oppenheimer Aharon freheb: אופנהיימר Whereas you would rather like to see (mind language and lack of $b above): Oppenheimer, Aharon Hebrew: אופנהיימר, אהרן A patch will follow. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 11890] New: Control-Click/Command-Click to open a link in a new tab not consistently working
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11890 Bug ID: 11890 Summary: Control-Click/Command-Click to open a link in a new tab not consistently working Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: ed.veal(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Control-Click (PC) or Command-Click normally opens any link in a web browser into a new tab. After the 3.14 upgrade, we have discovered inconsistency in links not always having this behavior anymore on search.pl and detail.pl. This has been replicated on Master as well. On search.pl, control-clicking or command-clicking on the title links opens the link in the same window. You have to actually right-click on the link and tell the browser to open the link in a new tab. The linked author field in the search results, the call numbers, the facets on the left-hand side of the screen, the links at the top -- all will open in a new tab with the control-click or command-click option. On detail.pl, if the back to search results/next record/previous record links are present, control-clicking or command-clicking the normal/MARC/ISBD/Items/Holds/Checkout History/Barcode links open the information on the same screen. If you switch to one of the other tabs, the back to search results link is gone, and this keyboard shortcut works again. I do not see this same behavior in the OPAC. Disabling all javascript causes it to return to normal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 13516] New: Display issue for search results with items both checkout out and lost
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13516 Bug ID: 13516 Summary: Display issue for search results with items both checkout out and lost Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the staff search results, if an item is both checked out and lost, the result will appears as two item lines like this: http://screencast.com/t/2Hczv1jhL when it should look like this: http://screencast.com/t/JDV2cGNq -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 12135] New: Pending suggestions table width is wrong
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12135 Bug ID: 12135 Summary: Pending suggestions table width is wrong Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It looks like the table for pending suggestions is out of whack. All the other tabs are formatting to a width of 1006px, but the pending request are formatting the table to a width of 1256px. Apparently this can't be fixed with jQuery. I can adjust the widths of the tables on the other tabs, but for some reason it won't work on this particular table. This is the jQuery I used: $("#ASKEDt").css("width","1006px"); If I change the ID to one of the other tables, it works just fine. May be part of the bug. It looks like it applies, but when you click the tab to look at this table, the old size appears, which makes me think the style is being applied when the tab is clicked, and overridden. The funny thing is that it doesn't do this with the other tabs. The jQuery override is applied and sticks, even after changing between the tabs. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 10976] New: the assistant for reports uses the wrong value for the list of item types
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10976 Bug ID: 10976 Summary: the assistant for reports uses the wrong value for the list of item types Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When using the assistant to create a new report (guided_reports.pl), if you choose to limit according to the itemtype, the generated code is <<itype|itemtype>>, but the proper value for the report to work should be <<itype|itemtypes>> (with an extra 's'). (This was also wrong in the wiki. Fixed now.) -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 12253] New: MARCURLS not showing in OPAC basket
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12253 Bug ID: 12253 Summary: MARCURLS not showing in OPAC basket Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, URLs are not showing up in the OPAC basket (more detail view). This is because the template tries to get them with the key "MARCurlS" when the actual key is "MARCURLS". The template should also use MARCurl.url instead of MARCurl.part, so that users can see the actual URL rather than the "Materials specified". -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 12192] New: Template toolkit code in HTML attributes is picked up into po-files
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12192 Bug ID: 12192 Summary: Template toolkit code in HTML attributes is picked up into po-files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr If TT code is used in title, alt, value, label, etc. attribute, the code is picked up into the po-files as-is, instead of replacing it with a placeholder. For example: <a href="[% url %]" title="Remove facet [% facet.facet_link_value | html %]">x</a> shows up in the po-files as: msgid "Remove facet [% facet.facet_link_value | html %]" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 11574] New: Printing Lists
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11574 Bug ID: 11574 Summary: Printing Lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 24474 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24474&action=edit Sections that shouldn't print when printing list Would like to see list printing from staff client cleaned up. Right now, the list printing includes buttons and the "Add and item..." section below. These should be omitted to save paper. -- You are receiving this mail because: You are watching all bug changes.

1 41