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

[Bug 6035] New: Mobile interface for OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '13

08 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6035 Bug #: 6035 Summary: Mobile interface for OPAC Classification: Unclassified Change sponsored?: Seeking cosponsors Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Koha could use a proper mobile interface for the OPAC. -- 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 11

[Bug 7463] New: don't show item number on fines
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '13

08 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7463 Bug #: 7463 Summary: don't show item number on fines Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com When you look at the Fines tab on the patron record it shows the item number and a link to 'view item' - the item number isn't necessary and actually confuses things because no one uses the item number - it should show the barcode or no item at all (since there is a link to the item anyway). -- 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 1

[Bug 5832] New: rss.pl limited to 15 results
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '13

08 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5832 Bug #: 5832 Summary: rss.pl limited to 15 results Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Command-line Utilities AssignedTo: gmcharlt(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org When fetching items, rss.pl puts a hard LIMIT 15 clause on the end of the query. This is to ensure compatibility with RSS 0.91. This restriction is lifted with RSS 0.92, but rss.pl does not recognize this. The rss.pl script should have a mechanism for identifying the RSS version, and if it's 0.92 or greater, allowing for users to specify their own LIMIT clause on the query. -- 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 2

[Bug 6206] New: can't change framework in the middle of cataloging
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '13

08 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6206 Bug #: 6206 Summary: can't change framework in the middle of cataloging Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com If you're cataloging a record and you change the framework after entering data all the data is erased and you're left with a blank record. This is in FF4 on Mac OSX -- 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 6

[Bug 8036] New: item type on purchase suggestion blank
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '13

07 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8036 Priority: P5 - low Change sponsored?: --- Bug ID: 8036 Assignee: henridamien(a)koha-fr.org Summary: item type on purchase suggestion blank Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha Created attachment 9381 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9381&action=edit default item type I have confirmed this on 3 different 3.8 installs. When making a purchase suggestion in the OPAC the item type pull down always says 'default' - it used to have the item types in it. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 10385] New: item-level_itype checks need to be refactored
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '13

06 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10385 Bug ID: 10385 Summary: item-level_itype checks need to be refactored Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com Checks on the item-level_itypes system preference are scattered throughout the code, and there have been a large number of bugs concerning cases where such a check is missing. I propose checks of this system preference be moved as far down the stack as possible. Specifically, all routines that fetch items from the database should check the syspref to determine the correct item type column and return it via (say) an "item_type" key in the response, to distinguish it from 'itemtype' and 'itype'. The only code that would see 'itype' or 'itemtype' would be code directly related to modifying items. Further, the syspref would be checked in as few places as possible. I further propose pinning down the semantics of the item-level_itypes as follows: - when ON, the item type is *always* taken from items.itype for all display and circulation purposes - when OFF, the item type is *always* taken from biblioitems.itemtype In particular, the current behavior of GetItem (fetch the itype from the item if it's not blank, otherwise fall back to the biblioitem itemtype), would be modified. Related bugs include: - Bug 7491 - Bug 7492 -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 7492] New: Split item-level_itypes in two
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '13

06 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7492 Bug #: 7492 Summary: Split item-level_itypes in two Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: magnus(a)enger.priv.no QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com As pointed out in Bug 7491, the item-level_itypes syspref has two functions. In the words of the documentation: * This preference determines whether the item type Koha uses for issuing rules will be an attribute of the bibliographic record or the item record. * It also determines if the item type icon appears on the OPAC search results. If you have the preference set to 'biblio record' then Koha displays the item type icon on the search results to the left of the result info. It seems to me that it would be a good idea to have two different sysprefs for this - libraries might want to alter the display in the OPAC independently from how they handle their issuing rules. -- 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 2

[Bug 5920] New: remove html from downloaded reports
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '13

06 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5920 Bug #: 5920 Summary: remove html from downloaded reports Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Reports AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Right now if you want to have HTML in your report you can do so - usually this is used to turn bib numbers into links or titles into links - etc. It would be great if the export to CSV function stripped out the html tags before exporting so that you could have a report that printed to the screen with links, but when downloaded just showed you the necessary data without any extraneous tags. -- 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 2

[Bug 5678] New: Translations Manager
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '13

05 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5678 Summary: Translations Manager Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: translate.koha-community.org AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: vicente(a)masmedios.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 I would like to include a new section on the intranet of Koha, at "Koha Administration". It'll be named "Translations Manager" and we'll be able to perform the following actions: 1) Editing an existing language label: 1.1) The interface allows you to choose a language of a set of languages that have been defined/installed. 1.2) PO files will be read for the language chosen to create a template combo-box. 1.3) For the selected template, the system will generate a combo-box with the language labels in the template. Selecting a label will display a text field where you can edit/save your translation. 2) Creating a new language: 2.1 Create a language: a) If an initial PO exists in KOHA (although it hasn’t been defined/installed in the initial Koha configuration) it will be possible to choose it from the languages available. b) If an initial PO does not exist in KOHA it will be possible to create it. 2.2) The system will create the directory structure from the English version (LangInstaller.pm install) and it will create PO files from the English version if they do not exist. 2.3) Once the language is created, we'll be able to edit their labels as indicated in step 1). -- 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 3

[Bug 6455] New: Warning message Patron card creator
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '13

05 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6455 Bug #: 6455 Summary: Warning message Patron card creator Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: vimal0212(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org When we try to create new batch of patrons from Tools > Patron Card Creator it shows following message, WARNING: The database returned an error while saving batch 0. Please have your system administrator check the error log for details. -- 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 1