http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9703 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Assignee|gmcharlt@gmail.com |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Created attachment 15646 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15646&action=edit Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine I've included a lot of text and an elaborate test plan below regarding this enhancement, but it's actually quite trivial in itself, as it doesn't change any default Koha behaviour. Its potential usage might be controversial, but I'm happy to discuss and I think there's no harm in putting this patch through. Test Plan: 1) Add multiple Keyword to MARC Mappings to your Koha instance using the "author" field name (e.g. Field name: "author", MARC field: "100", MARC subfield: "a", Field name: "author", MARC field: "100", MARC subfield: "c") 2) Make sure that you have a bibliographic record that has a 100$a and 100$c entry (try anything by "Somme theologique: les actes humaines" by Saint Thomas Aquinas), and that you have this catalogued with the same MARC Bibliographic Framework where you made those Keyword to MARC Mappings. 3) View that record in the OPAC (you'll probably just see "by Thomas," 3) Add the following code to your opac-detail.pl page after "my $dat" is called: "my $author = GetRecordValue('author', $record, GetFrameworkCode($biblionumber), 'as_string'); if ($author) { $dat->{author} = $author ; } 4) Refresh your OPAC page 5) Note that you should now have "by Thomas, Aquinas, Saint," showing -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9703 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #3 from David Cook <dcook@prosentient.com.au> --- Actually, I don't think that this patch/concept is quite ready for master. I do think the Keyword to MARC mapping has a lot of potential to increase the customizability of the "Normal" view of bibliographic records for libraries in a user-friendly way that doesn't rely on XSL, and this is something important that we should be developing. However, I think we need a systematic approach for how these mappings can overwrite the default values supplied to the detail template (and maybe even the search results and lists although I would be hesitant with those). I don't think the use of an "as_string" parameter is necessarily the best way of doing this, since it glues together the results of an array with spaces when you might want to include punctuation. -- Ideally, I think the Keyword to MARC mapping table should include an extra optional column for glue/punctuation, which will follow each mapping. In some cases, you might not want to include punctuation, because your descriptive standard might already include it. Say, you want the "author" field to contain 100$a, 100$c, and 100$d (USMARC). The punctuation might already be included in those subfields. If it isn't, then you can add optional punctuation in your Keyword to MARC mapping to add it in. N.B. this would be more useful for situations when you're combining different MARC fields or disparate subfields from a field together to create an element on the Normal detail page. In any case, I think this is better than having to hard-code the punctuation into the templates like we currently do. -- You are receiving this mail because: You are watching all bug changes.