| Summary: | Add authorized values for Relator Terms | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Esther Melander <esther.melander> |
| Component: | System Administration | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | gmcharlt |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Esther Melander
2024-02-01 17:02:56 UTC
(In reply to Esther Melander from comment #0) > Bug 34677 updates the relator terms and codes list. There are authorized > values for Relator Terms but not for Relator Codes. This should be separated > out so that the codes can be selected for $4, which is more correct for that > subfield. While it is possible for a user to add authorized values for > Relator Codes, it would be nice if they were included. I think this is not quite right: RELTERMS AV category has the authorised values for the codes, not the terms. What happens is that we resolve the code in the MARC record to the term when the XSLT is parsed for display automatically. So you see the description when looking at it in Koha, but when you export the record, it has the code. So we have $4, but are missing values for $e maybe? I wonder if using AV codes is the best way here. Maybe we should have a cataloguing plugin that automatically populates the other subfield depending on the value chosen? Yes, I can see the codes as the authorized value. However, when selecting RELTERMS for $4 in the framework, the description is what is displayed. The description is equivalent to the terms and not the codes. $4 should display the codes as a code rather than the associated term as that should be in $e. This is an example: 100 1 Presthus, Robert Vance, ǂe author ǂ4 aut Also, reading up on this, $4 is repeatable. Another example: 100 1 Wagner, Kate, ǂe composer, ǂe instrumentalist ǂ4 cmp ǂ4 itr The example above also suggests there is not always a one to one relationship between a term and a code. Would a plugin address what data is displayed? It would be easier to maintain one list of codes and terms. I think we need to separate display from what is actually stored in the MARC record. The trick we use for AVs in frameworks make it so you always see the AV description, while the code is actually stored in the record. If you want display and MARC record to match, the easiest way would be to edit the RELTERMS list and set the description to the code values. Similar, if we wanted the terms, we'd need to set code and description to the term, which doesn't really feel like an all that great idea (not sure if the code length is still limited). Using a cataloging plugin might be actually be more flexible and could help if we want fields to depend on each other in some way. |