Bug 29539 - UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a
Summary: UNIMARC: authority number in $9 displays for thesaurus controlled fields inst...
Status: Pushed to oldstable
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: George Veranis
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-20 16:50 UTC by Rafael Antonio
Modified: 2024-09-06 00:57 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This fixes the display of authority terms in the OPAC for UNIMARC systems. The authority record number was displaying instead of the term, depending on the order of the $9 and $a subfields (example for a 606 entry: if $a then $9, the authority number was displayed; if $9 then $a, the authority term was displayed).
Version(s) released in:
24.11.00,24.05.02,23.11.07
Circulation function:


Attachments
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a (3.19 KB, patch)
2023-09-14 06:39 UTC, George Veranis
Details | Diff | Splinter Review
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a (3.24 KB, patch)
2024-01-22 22:37 UTC, David Nind
Details | Diff | Splinter Review
Bug 29539: (follow-up) remove tag_onesubject template (7.33 KB, patch)
2024-01-30 07:50 UTC, Fridolin Somers
Details | Diff | Splinter Review
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a (3.24 KB, patch)
2024-02-05 20:29 UTC, David Nind
Details | Diff | Splinter Review
Bug 29539: (follow-up) remove tag_onesubject template (7.38 KB, patch)
2024-02-05 20:29 UTC, David Nind
Details | Diff | Splinter Review
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a (6.78 KB, patch)
2024-03-15 10:40 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Antonio 2021-11-20 16:50:08 UTC
When it hapens UNIMARC record to have $9 after $a on biblio_metadata record like  

<datafield tag="606" ind1=" " ind2=" ">
    <subfield code="a">Portugal</subfield>
    <subfield code="9">12005</subfield>
  </datafield>

OPAC details display the authority number and not the term.

If we change record for  

<datafield tag="606" ind1=" " ind2=" ">
    <subfield code="9">12005</subfield>
   <subfield code="a">Portugal</subfield>
  </datafield>

it display the term.

Is it a bug? The only piece of XSLT code I see for such reason is at UNIMARCslimUtils.xsl file

<xsl:choose>
                <xsl:when test="marc:subfield[@code=9]">


Any comment?
Comment 1 Rafael Antonio 2021-11-22 09:23:04 UTC
This problem hapens with all fields that are validate through thesaurus and use $9 to link to authority, not only 606
Comment 2 George Veranis 2022-01-05 12:43:30 UTC
I confirm that problem exist on version 20.05 and after for all unimarc installations. And the problem should be on template onesubject at UNIMARCslimUtils.xsl on opac , at intranet is working as expected.
Comment 3 Rafael Antonio 2022-01-05 15:36:02 UTC
I have tried to compare UNIMARCslimUtils release 20 and release 18 but it seems there is no difference on template onesubject.
Testing intranet UNIMARCslimUtils on OPAC it does not work. So the only way is to try to find the bug or reson for such.

As you can see this is the result on OPAC

Country: Portugal.
Publication: Lisboa : Gabinete da Inspecção-Geral do Trabalho, 1992
Subject - Topical Name: 9504 | 11070 | 9501 | 9200 | 11252 | 11305 | 8439 | 6383 | 8128
 
And similar display for Intranet

Country: Portugal.
Publication: Lisboa : Gabinete da Inspecção-Geral do Trabalho, 1992
Subject - Topical Name: Inspecção-Geral do Trabalho | Relatório | Inspecção do trabalho | Higiene do trabalho | Saúde no trabalho | Segurança no trabalho | Doença profissional | Acidente de trabalho | Dados estatisticos

Who can help?
Comment 4 Katrin Fischer 2022-01-09 00:04:08 UTC
i had a look at the XSLT code here, but it is a bit complicated. Adding Frido as he might have more UNIMARC knowledge than I.

If you compare files, please note that there are 2 versions of UNIMARCslimUtils.xsl - one on staff and one on OPAC side. So maybe comparing those 2 would give some more hints.
Comment 5 Rafael Antonio 2022-01-09 00:13:05 UTC
I am not so sure if the problem is on XSLT file or any perl function that was changed and this can be a side efect
Comment 6 Katrin Fischer 2022-01-09 00:14:27 UTC
The display is rendered from the MARCXML record in the database using XSLT. There are some replacements where authorised values are linked to fields, but they should not be to blame here I think.
Comment 7 George Veranis 2022-01-10 08:58:56 UTC
For the moment I solve that problem by using the template "tag_subject" from the MARC21slimUtils.xsl and it works fine. and adding also the same codes and subdivCodes from template tag_onesubject that seems to have the problem, but my xslt knowledge is not the best at the moment to solve it or to understand what is wrong, so I decided to use the same template as MARC21.  

 <xsl:template name="tag_subject">
 <xsl:param name="tag" />
  <xsl:param name="label" />
   <xsl:param name="spanclass" />
    <xsl:if test="marc:datafield[@tag=$tag]">
     <span class="results_summary subjects {$spanclass}">
      <span class="label"><xsl:value-of select="$label"/>: </span>
       <xsl:for-each select="marc:datafield[@tag=$tag]">
<a>
 <xsl:choose>
<xsl:when test="marc:subfield[@code=9]">
        <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=su:<xsl:value-of select="marc:subfield[@code='a']"/></xsl:attribute>
 </xsl:otherwise>
</xsl:choose>
  <xsl:call-template name="chopPunctuation">
 <xsl:with-param name="chopString">
         <xsl:call-template name="subfieldSelect">
            <xsl:with-param name="codes">abcdfijkmpnptvxyz</xsl:with-param>
          <xsl:with-param name="subdivCodes">ijknpxyz</xsl:with-param>
           <xsl:with-param name="subdivDelimiter">-- </xsl:with-param>
 </xsl:call-template>
</xsl:with-param>
 </xsl:call-template>
 </a>
   <xsl:if test="not (position()=last())">
    <xsl:text> | </xsl:text>
      </xsl:if>
      </xsl:for-each>
       </span>
</xsl:if>
  </xsl:template>
Comment 8 Fridolin Somers 2022-01-15 06:46:16 UTC
Hi,

This is a very strange feature in UNIMARC XSLT that aim to look for several $9 in authority fields.
We should remove it.
Comment 9 Rafael Antonio 2022-01-15 10:33:00 UTC
Use of $9 is very important for searching using Thesaurus (authority records).
May be we need to review XSLT but if Vearnis fix works we can wait for next release we open to be solved
Comment 10 George Veranis 2023-09-14 06:39:09 UTC
Created attachment 155604 [details] [review]
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a

When you try to dislpay a bibliographic record on unimarc that has subjects
linked with authorities then only the $9 is displayed as link instead of the
content of $a and it's subdivisions, if any.

To test:
1) You will need to have a bibliographic record with at least one subject
autority connected in unimarc framework.
2) View that record on OPAC on detail display. The subject will display as
a number ( $9 )  and you cannot see the text/term of the subject ( $a )
3) Apply patch
4) Repeat step 2
5) The subject display in a normal way based on content $a - or more subfields

Sponsored-by: National Library of Greece
Comment 11 David Nind 2023-10-08 23:28:38 UTC
I've changed the assignee.

I couldn't replicate the issue on the current master (using the sample data in koha-testing-docker) - the topical terms for a record displayed correctly in the OPAC.

Is this for 21.05 only?
Comment 12 Thibault Keromnès 2024-01-22 11:43:42 UTC
Couldn't replicate either on a sandbox (display is ok whether it's 606$a and then 606$9 or 606$9 and then 606$a)
Comment 13 Andreas Roussos 2024-01-22 19:26:17 UTC
(In reply to David Nind from comment #11)
> I've changed the assignee.
Thanks, David.
 
> I couldn't replicate the issue on the current master (using the sample data
> in koha-testing-docker) - the topical terms for a record displayed correctly
> in the OPAC.
I just managed to replicate the issue using KTD. Since I already had a
MARC21 KTD container up and running on the current master b54da05c73
and didn't want to lose my bash history, I ran these commands to set it
up with the UNIMARC sample data and fix the Zebra index configuration:

reset_all unimarc
sed -i.safe 's/marc21/unimarc/g' \
 /etc/koha/sites/kohadev/zebra-authorities-dom.cfg \
 /etc/koha/sites/kohadev/zebra-biblios-dom.cfg
koha-rebuild-zebra -a -b -f -v kohadev

I then linked the same Topical Name subject with field 606 of a test
biblio twice, and changed the order of the subfields so that in the
first 606 the $9 would appear after the $a and in the second 606 the
$a would appear after the $9. In the OPAC details view for that biblio
I got exactly what Rafael describes in this Bug's Description.

> Is this for 21.05 only?
No, it manifests on the current master, too. I've changed the Version.
Comment 14 Andreas Roussos 2024-01-22 19:31:02 UTC
(In reply to Thibault Keromnès from comment #12)
> Couldn't replicate either on a sandbox (display is ok whether it's 606$a and
> then 606$9 or 606$9 and then 606$a)
That's interesting, I actually replicated the problem today by setting
up a UNIMARC flavour instance on ByWater Solutions' sandbox server (on
the current master b54da05c73 and without applying George's patch).

As you can see here the first Topical subject does not display properly:
https://opac-abefore9.sandbox.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=53

The order of the relevant subfields in that biblio is as follows:
606 _a écosystèmes
    _9 6410
606 _9 6410
    _a écosystèmes
Comment 15 David Nind 2024-01-22 22:37:20 UTC
Created attachment 161262 [details] [review]
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a

When you try to dislpay a bibliographic record on unimarc that has subjects
linked with authorities then only the $9 is displayed as link instead of the
content of $a and it's subdivisions, if any.

To test:
1) You will need to have a bibliographic record with at least one subject
autority connected in unimarc framework.
2) View that record on OPAC on detail display. The subject will display as
a number ( $9 )  and you cannot see the text/term of the subject ( $a )
3) Apply patch
4) Repeat step 2
5) The subject display in a normal way based on content $a - or more subfields

Sponsored-by: National Library of Greece
Signed-off-by: David Nind <david@davidnind.com>
Comment 16 David Nind 2024-01-22 22:45:47 UTC
Thanks Andreas for the steps on how to reproduce the issue!

I have now tested and signed off using KTD (koha-testing-docker).

Updated test plan:
1. KTD startup: edit your .env file and change KOHA_MARC_FLAVOUR=unimarc
2. Start up KTD as normal: ktd pull and ktd up
3. Edit any record so that it has two 606 entries - NOTE: The order displayed in the editor is important:
   - For record 560 ([Le ]Jardin des Henderson : roman [LIVR] / Hermary-Vieille Catherine), remove the existing values in the 606 field
   - Add these values:
     606 _a écosystèmes
         _9 6410
     606 _9 6410
         _a écosystèmes
   NOTE: The sample data for UNIMARC records is very incomplete - you will need to:
         1. Add data for the mandatory fields before you can save the record.
         2. Update the item(s) for the record so that any values with dropdown lists have valid values (otherwise you will have errors in the OPAC when you try to view the record).
4. View the record in the OPAC and staff interface:
   - OPAC: Subject - Topical Name: 6410 | écosystèmes 
   - Staff interface: Subject - Topical Name: écosystèmes | écosystèmes 
5. Apply the patch.
6. Restart everything.
7. View the record again in the OPAC and staff interface
   - OPAC: Subject - Topical Name: écosystèmes | écosystèmes
   - Staff interface: Subject - Topical Name: écosystèmes | écosystèmes
8. Experiment with changing the order and adding new terms - these should now display correctly, irrespective of the $a and $9 order in the record.
9. Sign off.
Comment 17 Marcel de Rooy 2024-01-26 09:52:48 UTC
-            <xsl:call-template name="tag_onesubject">

This is the last reference, right?
So we are using it no longer. Please remove dead code too.

This template contains a lot of additional logic. Could you or Fridolin explain what its purpose should have been?
Comment 18 Fridolin Somers 2024-01-30 07:34:21 UTC
(In reply to Marcel de Rooy from comment #17)
> 
> This template contains a lot of additional logic. Could you or Fridolin
> explain what its purpose should have been?

This was a try to show composed authority fields, with method called Rameau.
An field like 600 may contain an authority link for $a and another authority link for $x. In this case the $9 must be before the linked field :
  $9 888
  $a History
  $9 999
  $x Antiquity

But this is not implemented in Koha record edition so it is logical to remove this behavior.
Comment 19 Fridolin Somers 2024-01-30 07:50:56 UTC
Created attachment 161622 [details] [review]
Bug 29539: (follow-up) remove tag_onesubject template

Also:
Restores the <span class="value">
Replaces "not(position()=last())" with the more used "position() != last()"
Removes unecessary change in <xsl:param name="spanclass" />
Comment 20 Fridolin Somers 2024-01-30 07:53:03 UTC
Thanks everyone for moving this dirty bug forward ;)
Comment 21 David Nind 2024-02-05 20:29:03 UTC
Created attachment 161768 [details] [review]
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a

When you try to dislpay a bibliographic record on unimarc that has subjects
linked with authorities then only the $9 is displayed as link instead of the
content of $a and it's subdivisions, if any.

To test:
1) You will need to have a bibliographic record with at least one subject
autority connected in unimarc framework.
2) View that record on OPAC on detail display. The subject will display as
a number ( $9 )  and you cannot see the text/term of the subject ( $a )
3) Apply patch
4) Repeat step 2
5) The subject display in a normal way based on content $a - or more subfields

Sponsored-by: National Library of Greece
Signed-off-by: David Nind <david@davidnind.com>
Comment 22 David Nind 2024-02-05 20:29:06 UTC
Created attachment 161769 [details] [review]
Bug 29539: (follow-up) remove tag_onesubject template

Also:
Restores the <span class="value">
Replaces "not(position()=last())" with the more used "position() != last()"
Removes unecessary change in <xsl:param name="spanclass" />

Signed-off-by: David Nind <david@davidnind.com>
Comment 23 Marcel de Rooy 2024-03-15 10:40:06 UTC
Created attachment 163191 [details] [review]
Bug 29539: UNIMARC: authority number in $9 displays for thesaurus controlled fields instead of content of $a

When you try to dislpay a bibliographic record on unimarc that has subjects
linked with authorities then only the $9 is displayed as link instead of the
content of $a and it's subdivisions, if any.

To test:
1) You will need to have a bibliographic record with at least one subject
autority connected in unimarc framework.
2) View that record on OPAC on detail display. The subject will display as
a number ( $9 )  and you cannot see the text/term of the subject ( $a )
3) Apply patch
4) Repeat step 2
5) The subject display in a normal way based on content $a - or more subfields

Sponsored-by: National Library of Greece
Signed-off-by: David Nind <david@davidnind.com>

Bug 29539: (follow-up) remove tag_onesubject template

Also:
Restores the <span class="value">
Replaces "not(position()=last())" with the more used "position() != last()"
Removes unecessary change in <xsl:param name="spanclass" />

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 24 Katrin Fischer 2024-03-15 14:31:39 UTC
Hi Marcel, I tried to apply the patches in the attached sequence and the other way around, I always end up with: 

Apply? [(y)es, (n)o, (i)nteractive] i
Applying: Bug 29539: (follow-up) remove tag_onesubject template
error: sha1 information is lacking or useless (koha-tmpl/opac-tmpl/bootstrap/en/xslt/UNIMARCslimUtils.xsl).
error: could not build fake ancestor
Patch failed at 0001 Bug 29539: (follow-up) remove tag_onesubject template
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Patch left in /tmp/Bug-29539-follow-up-remove-tagonesubject-template-daluwkeh.patch
kohadev-koha@kohadevbox:koha(master|AM 1/1)$ git log

Can you please check/rebase on latest master?
Comment 25 Marcel de Rooy 2024-03-18 09:15:30 UTC
(In reply to Katrin Fischer from comment #24)
> Hi Marcel, I tried to apply the patches in the attached sequence and the
> other way around, I always end up with: 
> 
> Apply? [(y)es, (n)o, (i)nteractive] i
> Applying: Bug 29539: (follow-up) remove tag_onesubject template
> error: sha1 information is lacking or useless
> (koha-tmpl/opac-tmpl/bootstrap/en/xslt/UNIMARCslimUtils.xsl).
> error: could not build fake ancestor
> Patch failed at 0001 Bug 29539: (follow-up) remove tag_onesubject template
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> When you have resolved this problem run "git bz apply --continue".
> If you would prefer to skip this patch, instead run "git bz apply --skip".
> To restore the original branch and stop patching run "git bz apply --abort".
> Patch left in
> /tmp/Bug-29539-follow-up-remove-tagonesubject-template-daluwkeh.patch
> kohadev-koha@kohadevbox:koha(master|AM 1/1)$ git log
> 
> Can you please check/rebase on latest master?

I would be happy to leave that to the author.
Comment 26 Katrin Fischer 2024-03-18 09:18:50 UTC
That's alright, just easier for someone with the branch still around.
Comment 27 Andreas Roussos 2024-05-30 08:27:18 UTC
There's a single sign off in Comment 23 which appears to involve
two patches (instead of two separate sign offs, one per patch).
I think that's the reason the current set of patches (attachment
ids 161768 and 163191) does not apply cleanly.
Comment 28 David Nind 2024-06-04 00:34:53 UTC
Comment on attachment 161769 [details] [review]
Bug 29539: (follow-up) remove tag_onesubject template

Can confirm that the combined patch still applies.

I have obsoleted the separate follow-up patch and will change the status back to Passed QA.
Comment 29 Martin Renvoize 2024-06-10 11:03:58 UTC
Thanks for all the hard work!

Pushed to main for the next 24.11.00 release as RM Assistant
Comment 30 Lucas Gass 2024-06-27 21:55:58 UTC
Backported to 24.05.x for upcoming 24.05.02
Comment 31 Fridolin Somers 2024-07-17 13:24:18 UTC
Pushed to 23.11.x for 23.11.07
Comment 32 wainuiwitikapark 2024-07-19 03:15:17 UTC
not backporting to 23.05.x unless requested
Comment 33 Tiago Simões 2024-09-05 15:29:08 UTC
Hi! Would it be possible to backport it to 22.11? At our library, we've been struggling with this problem for a long time and I'm glad a solution was finally found, as we have a lot of records in the situation described by Rafael António.
Comment 34 Lucas Gass 2024-09-05 15:38:35 UTC
(In reply to Tiago Simões from comment #33)
> Hi! Would it be possible to backport it to 22.11? At our library, we've been
> struggling with this problem for a long time and I'm glad a solution was
> finally found, as we have a lot of records in the situation described by
> Rafael António.

Tiago, Wainu declined to backported this to 23.05. Although it sounds like she could be persuaded to do so? 

If it can be backported to 23.05 there is a chance it will also backported to 22.11.
Comment 35 Tiago Simões 2024-09-05 15:52:14 UTC
(In reply to Lucas Gass from comment #34)
> (In reply to Tiago Simões from comment #33)
> > Hi! Would it be possible to backport it to 22.11? At our library, we've been
> > struggling with this problem for a long time and I'm glad a solution was
> > finally found, as we have a lot of records in the situation described by
> > Rafael António.
> 
> Tiago, Wainu declined to backported this to 23.05. Although it sounds like
> she could be persuaded to do so? 
> 
> If it can be backported to 23.05 there is a chance it will also backported
> to 22.11.

I understand. If I'm the only one wanting this, it's understandable that she doesn't backport it. I'll try and make the case to our IT department to upgrade to a more recent version sooner than planned, then.

Thanks anyway!
Comment 36 wainuiwitikapark 2024-09-06 00:57:23 UTC
I can have a look at backporting this to 23.11 for the next release