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

[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 9361] New: MARC 610 and 611 fields in bulk imports are not indexed
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 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 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

[Bug 10066] New: updating biblio return undefined error if linked authority does not exist in db
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10066 Bug ID: 10066 Summary: updating biblio return undefined error if linked authority does not exist in db Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: siewyee2(a)yahoo.com descrption of problem: updating biblio return undefined error if previouly linked authority does not exist in db steps to recreate: 1. link an authority to biblio 2. manually delete authority from db 3. either a. run link_bibs_to_authorities.pl or b. update the biblio from staff client 4. will return undefined error for field we wanted to clear all linked authorities subfield $9 from biblios. run into this error. fixed the code, but dont really know if it is the best approach. attaching code fix for reference. ######################################################################### AuthoritiesMarc.pm line 1194 added one line: return unless defined($record); } else { #fix undefined error if authorized heading does not exist in db return unless defined($record); # foreach my $field ($record->field('1..')) { ########################################################################## Biblio.pm line 669 added one line: return unless defined($authorized_heading); my $authorized_heading = C4::AuthoritiesMarc::GetAuthorizedHeading( { 'authid' => $authid } ); #fix undefined error if authorized heading does not exist in db return unless defined($authorized_heading); # return ($field->as_string('abcdefghijklmnopqrstuvwxyz') eq $authorized_heading); -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9110] New: GetAuthorizedHeading Can't call method "field" on an undefined
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9110 Bug ID: 9110 Summary: GetAuthorizedHeading Can't call method "field" on an undefined Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: matted-34813(a)mypacks.net I deleted my auth_header records; When runnong misc/link_bibs_to_authorities.pl With LinkerRelink = Do I get: GetAuthorizedheading Can't call method "field" on an undefined value at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 1191 In my case, I deleted the auth_header records, since I wanted to regenerate them. They had lots of dups since I was upgrading from a 3.0 version to (master pre-3.10). I reindexed the bibs and auths, but since I shouldn't find any auths, and though my bibs might have dangling $9 links, there might need to be a check that $record->field is viable. other settings: CatalogModuleRelink Do LinkerKeepStale = do not LinkerModule - default AutoCreateAuthorities - either setting BiblioAddsAuthorities - allow UseAuthoritiesForTracings -either setting Fuzzy not enabled. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 5706] New: Search, create lists and Export authorities from staff interface
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5706 Summary: Search, create lists and Export authorities from staff interface Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: eb(a)efdss.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 It would be useful to be able to perform certain operations on authority records in the staff interface. Specifically 1) Search by creation date 2) Search by control number 3) add to a list or create a list from a search results page 4) export MARC 5) batch edit authorities -- 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 5

[Bug 6839] New: placement of subfield 9 in 6XX and 7XX headings changes staff view
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6839 Bug #: 6839 Summary: placement of subfield 9 in 6XX and 7XX headings changes staff view Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: MARC Authority data support AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com We've noticed that where the subfield 9 in the 6XX and 7XX fields is first in the list of subheadings causes there to be dashes in the staff "Normal" view of the record. That subfield seems to be used to hold the link to the authority record, When a new heading is added and the record saved, making a link to the authorities, sometimes the 9 is first and sometimes second and sometimes last. But if it is first (before the a) there are dashes in front as if the subfield a were a subheading rather than a heading. The problem is that if the subfield 9 is first, while it's not pushed to the subfields loop in the GetMarc<whatever> subroutines of C4/Biblio.pm, it's still counted, and the next subfield is viewed as "second" even though it's actually first. This means a separator is put in front of it. -- 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 11823] New: Add the "Total sublevels ordered" column to the funds list.
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '14

29 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11823 Bug ID: 11823 Summary: Add the "Total sublevels ordered" column to the funds list. 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: fcapovilla(a)live.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 25554 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25554&action=edit Add the total ordered amount to the funds list. This patch adds the "Total sublevel ordered" columns which works like the "Total sublevel spent" column, but for acquisitions which were ordered but not received. Sponsored-by: CCSR ( http://www.ccsr.qc.ca ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4