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

[Bug 12030] New: Common messages
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '14

03 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12030 Bug ID: 12030 Summary: Common messages 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 How about adding an editable list of common messages to the message feature in the patron checkout screen or in the custom restrictions? Of course, the message should be editable itself once it is selected and put in the text box. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 12453] New: Do not use by default Host-Item-Number in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '14

03 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12453 Bug ID: 12453 Summary: Do not use by default Host-Item-Number in UNIMARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Actually, in default UNIMARC install, 461$9 is indexed as Host-Item-Number, meaning it is used for analytical itemnumber. But most UNIMARC catalog use the analytical relation using unimarc_field_4XX.pl plugin on 461$a. In fact, this plugin is defined in default UNIMARC frameworks. If Host-Item-Number is defined but 461$9 is used for something else, it will lead to odd bugs. For example, records containing analytical items can not be deleted. I propose the comment the 461$9 indexing in UNIMARC zebra config. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 12205] New: It should be possible for Holds charges to count towards blocking checkout
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '14

02 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12205 Bug ID: 12205 Summary: It should be possible for Holds charges to count towards blocking checkout Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris(a)bigballofwax.co.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There are currently 2 systempreferences, which are used to determine what charges are counted towards blocking circulation RentalsInNoissueCharge and ManInvInNoissuesCharge Which means that someone may have 10000 in charges for holds, and still be able to checkout just fine. There needs to be a systempreference for this also -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 11566] New: Fixing accessibility on OPAC
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '14

02 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11566 Bug ID: 11566 Summary: Fixing accessibility on OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: manuelimel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We used wave.webaim.org toolbar to find errors on webpages -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 12420] New: syndetics content broken in bootstrap
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '14

02 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12420 Bug ID: 12420 Summary: syndetics content broken in bootstrap Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Syndetics cover images work in Koha, but not the other content -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 9361] New: MARC 610 and 611 fields in bulk imports are not indexed
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '14

02 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9361 Bug ID: 9361 Summary: MARC 610 and 611 fields in bulk imports are not indexed Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P4 Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: dpk(a)randomnotes.org See in 3.10.0, but may effect earlier versions as well. Import a bunch of records with 610 and 611 fields (as well as 650) (also 100, 110 and 111). Import, rebuild zebra index and then link_bibs_to_authorities. 610 and 611 entries do not get link to the appropriate authorities. The problem appears to be due to this commented code in lib/C4/Koha.pm: sub getFacets { my $facets; if ( C4::Context->preference("marcflavour") eq "UNIMARC" ) { $facets = [ ... } else { $facets = [ { idx => 'su-to', label => 'Topics', tags => [ qw/ 650a / ], sep => '--', }, # { # idx => 'su-na', # label => 'People and Organizations', # tags => [ qw/ 600a 610a 611a / ], # sep => 'a', # }, { idx => 'su-geo', label => 'Places', tags => [ qw/ 651a / ], sep => '--', }, { idx => 'su-ut', label => 'Titles', tags => [ qw/ 630a / ], sep => '--', }, Uncommenting the lines above for idx => 'su-na', followed by a rebuild of the zebra indexes (-v -b -a) and a link_bibs_to_authorities and 610s and 611s are now linked. Why was this stanza commented out? This appears to be empirically wrong. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 12061] New: tmpl_process3.pl new features
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12061 Bug ID: 12061 Summary: tmpl_process3.pl new features 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: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr New features on tmpl_process3.pl are needed to fulfill some tasks a) Cleaning of PO files ----------------------- When doing an update of translation files, old strings are preserved as comments (^#~). As a normal part of update this are removed with a script, and backup files removed. Translators that use to do offline translations remove those comments I propose a patch to remove obsoleted strings and backup files. (see Bug 8257) b) Multiple source dirs ----------------------- Currently only files below one source dir are scanned for strings. At this moment we have 3 opac files (prog/ccsr/bootstrap), but they share a lot of common strings (this date on master): bootstrap 2282 strings prog 2274 strings ccsr 109 strings But there are only 382 different strings between bootstrap/prog, and only 8 between prog/ccsr When we update translation files we need to do the same translation on each file, not a big problem for near complete translations, but a big task for new languages. An hypothetical unified PO file for all opac themes would have 2476 strings, and we need to translate only once each string. I know that prog is programmed to be phased out soon, but each bugfix needs to be ported to each current theme, so the need to translate each file. I propose a patch to add the ability to scan multiple source dirs to build a translation file, to make for example and unified opac PO file. This has not been requested by nobody yet, but is in my mind every time I translate. c) Include/Exclude scanned files by name ---------------------------------------- Currently we can exclude "dir" names, which was used for Bug 7934. But certain requests needs the ability to include/exclude files, for example we have a request to separate translations for each MARC dialect. It's a valid request. Normally a language will only use one MARC dialect, and only one will use NORMARC :) To do that we need a way to select which files to scan, or not scan (and also the previous feature, multiple source dirs) I propose a patch to add this feature, choosing which files to include/exclude given some strings to match with filenames -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 10308] New: Authorities linker should handle the "local subject added entry" fields.
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10308 Bug ID: 10308 Summary: Authorities linker should handle the "local subject added entry" fields. 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: robin(a)catalyst.net.nz CC: m.de.rooy(a)rijksmuseum.nl In MARC21, 690-699 are for locally defined subjects. These should be linked up to their appropriate authorities by the linker too. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 12674] New: GetMarcISSN should not return empty ISSN
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12674 Bug ID: 12674 Summary: GetMarcISSN should not return empty ISSN 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently, GetMarcISSN returns an array of all present ISSN on a specific record. Unlike the GetMarcISBN counterpart, it doesn't filter empty ISSNs out. To reproduce, run the attached regression test. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 11582] New: Have possibility to display authority subfield like bibliographic subfield
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11582 Bug ID: 11582 Summary: Have possibility to display authority subfield like bibliographic subfield Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, In 3.12, in advanced constraints of a bibliographic framework, we have now 5 choices for the visibility of the subfields. Is that we could have the same for authority types? Actually, there is 2 choice, hide or show all. Thanks, Marjorie -- You are receiving this mail because: You are watching all bug changes.

1 1