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

[Bug 4229] Need feature to view Label/Card batches from all branches
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4229 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Version|3.4 |master -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 5842] New: Cross-Reference links to authorized fields give incomplete search results
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5842 Bug #: 5842 Summary: Cross-Reference links to authorized fields give incomplete search results Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org The end-result problem is that clicking on cross-reference links in OPAC or staff XSLT title displays (authors, subjects) can produce incomplete results. The underlying problem is fairly complex. (Kudos to Bev Church for doing a lot of the in-depth research.) At the moment, there is only one system preference that controls authority creation -- BiblioAddsAuthorities. If you set the preference to OFF, staff cannot enter data in any authority controlled subfield. o Staff must first create an authority record and then link it to the bibliographic record if they manually create a bibliographic record. This is not a viable option for a lot of sites; they do not want to work with authority records or don't have the knowledge to create and then link a record. o Koha does no automatic bib/authority linking or authority creation if bibliographic records are imported using Z39.50 and the MARC import tool. If you set the preference to ON, staff can enter data in any authority controlled subfield. o Koha does automatic bib/authority linking and authority creation if bibliographic records are manually added or imported using Z39.50. o Koha does NO automatic bib/authority linking and authority creation if bibliographic records are added using the MARC import tool. With BiblioAddsAuthorities on, if a site does batch imports, the end result is that some authority controlled tags in their bibliographic records are linked to authority records while others are not. This affects the way Koha retrieves titles when users/staff click on the authority links in the full bibliographic record due to a searching enhancement. As it stands, the XSLT for both staff and OPAC checks for any authority record number in subfield $9 of authority controlled tags (the various author and subject fields) in the bibliographic record. If one exists, Koha uses the authority number as the search parameter instead of the name/subject string itself. For example, in an OPAC XSLT title record display, clicking on the author or one of the subjects will search against the titles linked to the authority record, not the equivalent author or subject zebra index. The search results may not be complete -- there are most probably fewer hits than if the search was done as a zebra title or subject search. See the following difference in how those cross-reference search links are formed with and without the link to the authority record: http://myserver/cgi-bin/koha/opac-search.pl?q=an:37 http://myserver/cgi-bin/koha/opac-search.pl?q=au:Carroll,%20Jonathan, http://myserver/cgi-bin/koha/opac-search.pl?q=an:38 http://myserver/cgi-bin/koha/opac-search.pl?q=su:Children%27s%20stories The most complete fix would be to modify the batch import tool to create the brief authority records, and do some substantial work on linking and merging authority records. I don't have the skill to do that, but I came up with a partial lipstick-on-a-pig solution. I created a system preference called CrossRefsUseAuthorities with this description: "If on, author and subject cross-references from title displays will use authority record to find related titles in staff and OPAC XSLT title display. If off, forces author and subject cross-reference searches to use the zebra indexes rather than the authority indexes; needed when BiblioAddsAuthorities is on but not all records have authorities (or there are multiple authority records). In that situation, a cross-reference search on the authority entry will not retrieve all titles." This tested and worked OK for OPAC XSLT, but I could not make it work for staff XSLT. The problem there seems to be that the part of C4/XSLT.pm which passes variables to the XSLT stylesheet is not being obeyed: foreach my $syspref ( qw/OPACURLOpenInNewWindow DisplayOPACiconsXSLT URLLinkText viewISBD OPACBaseURL CrossRefsUseAuthorities/ ) { Therefore, when I tried to modify the staff XSLT files similar to the change I did in the OPAC XSLT files: <xsl:choose> <xsl:when test="marc:subfield[@code=9] and $CrossRefsUseAuthorities!='0'"> <xsl:attribute name="href">/cgi-bin/koha/opac-search.pl?q=an:<xsl:value-of select="marc:subfield[@code=9]"/></xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/cgi-bin/koha/opac-search.pl?q=au:<xsl:value-of select="marc:subfield[@code='a']"/></xsl:attribute> </xsl:otherwise> </xsl:choose> I got error messages about invalid variables from trying to use the system preference. I don't know how to fix that problem. I am attaching a patch file for the part that I do have working (the syspref and the OPAC XSLT files). Can someone test those? Any takers to (a) solve the staff XSLT problem and/or (b) solve the underlying problem of authorities not being created with imports? -- 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 8

[Bug 5850] New: Should be able to define itypes or collection codes that generate "special handling" slip in SIP
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5850 Bug #: 5850 Summary: Should be able to define itypes or collection codes that generate "special handling" slip in SIP Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Koha should have the ablilty generate a "Special Handling" slip when items of defined itypes or collection codes are checked in through SIP. This enhancement would require the following: -An interface for defining the "special handling" itypes/collection codes -the SIP server to send the SIP client the correct message to print. We are using 3M self checks/smartchutes, but I think this behavior should work on most selfcheck solutions. -- 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

[Bug 6876] New: oai-pmh ListMetadataFormats marcxml definition
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6876 Bug #: 6876 Summary: oai-pmh ListMetadataFormats marcxml definition Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: benanderson(a)benanderson.us QAContact: koha-bugs(a)lists.koha-community.org this command: $ curl -s 'http://ubuntu/cgi-bin/koha/oai.pl?verb=ListMetadataFormats' | xmllint --format - results in : http://pastebin.com/raw.php?i=SU52snk3 I believe this is a problem: <schema>http://www.loc.gov/MARC21/slim http://www.loc.gov/ standards/marcxml/schema/MARC21slim.xsd</schema> <metadataNamespace>http://www.loc.gov/MARC21/slim http://www.loc.gov/ standards/marcxml/schema/MARC21slim</metadataNamespace> shouldn't it be this instead? <schema>http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd</schema> <metadataNamespace>http://www.loc.gov/MARC21/slim</metadataNamespace> and not quite as important, but somewhat relevant I think this: <metadataPrefix>marcxml</metadataPrefix> should be this: <metadataPrefix>marc21</metadataPrefix> according to this: http://www.openarchives.org/OAI/2.0/guidelines-marcxml.htm "It is recommended that the metadataPrefix "marc21" be used with this metadata format." -- 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 5388] New: Circulation of related/requiring items (like Book and CD sets)
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5388 Summary: Circulation of related/requiring items (like Book and CD sets) Change sponsored?: Seeking cosponsors Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: mjr(a)ttllp.co.uk QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 I think what we're looking at here is a sort of “requiring item” (sorry but I can't find the correct term for this) where unit 2 (the CD in this example) may only be issued if its requirements are met - that unit 1 is already issued to the borrower, and similarly on return. I would need to add an item field and linked MARC subfield to Koha so a cataloguer can set this as a reason not to issue an item but I don't see any particular problem with that. http://wiki.koha-community.org/wiki/Requiring_items_RFC -- 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 5270] New: 007 variable control builder/Specific Material Designation
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5270 Summary: 007 variable control builder/Specific Material Designation Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: reva12(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Field: 007 Material Type: Electronic Resource Bug in Specific Material Designation drop down list. When RE-opening the 007 builder to make changes to the coding, the Specific Material Designation drop down list for Electronic Resource reverts back to Tape Cartridge (code a) that is the Ist choice in the list. Unless one notices this reversion, one may be saving 007 and indicating wrongly that the item is Tape Cartridge. Reva -- 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

[Bug 4814] New: Item Type (MARC952 $c) not self-populating from imported OCLC bib
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4814 Summary: Item Type (MARC952 $c) not self-populating from imported OCLC bib Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: kbodling(a)mountvernon.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 After importing a bib record from OCLC, the item record Item Type in MARC 952 $c does not automatically populate itself with the value in the bib record's 942 $c unless I first open the bib record and save it. There is often no other reason to open the bib record in the edit screen at that point, so it would save 2 mouse clicks plus the wait time while the bib saves itself, in addition to having to select an Item Type while adding the Item Record, if that subfield self-populated as it does whenever the bib record has been opened and saved. (Note that no actual editing of the bib record need happen; all that has to happen is that it be opened in the edit screen and then saved, it that happens then the 952 $c fills itself with whatever is in the bib record's 942 $c.) Koha 3.01.00.061 on a hosted Linux bluehillils 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 GNU/Linux with Perl version 5.008008. -- 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 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 --- Comment #6 from Marc Véron <veron(a)veron.ch> --- Created attachment 34990 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=34990&action=edit [Signed-off] Bug 4402: Date filter on parcels.tt required db date format The date filters on the parcel page would only work with dates formatted YYYY-MM-DD. To test: - Select a vendor, that already has a few invoices - "Receive shipment" - you are on the parcels page - Use the From and To filters on the left, notice there is now a date picker on those fields - Verify the search works correctly for different date formats Followed test plan. Works as expected. Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4402] Date filter in parcels.tt requires db format dates
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4402 --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Not sure about the date handling - probably should have been using Koha::DateUtils? Feedback appreciated. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0