Summary: | When using an authorised value for suppression, record doesn't show as suppressed in staff interface | ||
---|---|---|---|
Product: | Koha | Reporter: | Kelly <training> |
Component: | Cataloging | Assignee: | Nick Clemens (kidclamp) <nick> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | andrewfh, fridolin.somers, katrin.fischer, m.de.rooy, nick, phil, victor |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
21.05.00,20.11.06,20.05.12
|
|
Bug Depends on: | |||
Bug Blocks: | 26116 | ||
Attachments: |
Bug 23406: Test for 1 or 'Yes' in record suppression
Bug 23406: Test for 1 or 'Yes' in record suppression Bug 23406: Unit test Bug 23406: Don't translate suppressed authorised values Bug 23406: Unit test Bug 23406: Don't translate suppressed authorised values Bug 23406: Unit test Bug 23406: Don't translate suppressed authorised values |
Description
Kelly
2019-07-31 16:46:12 UTC
Hi Kelly, I think it actually should show (bug 14377). Is your test user using custom XSLT by chance? (Couldn't test it yet, just a thought for now) This appears to be fixed in 19.11. Haven't figured out what's causing it in 19.05 and previous. But it doesn't work in master, oddly enough. Also, adding a dependency where strict mode causes some trouble in addbiblio (In reply to Andrew Fuerste-Henry from comment #3) > But it doesn't work in master, oddly enough. Also, adding a dependency where > strict mode causes some trouble in addbiblio It does work for me in master, even if the formatting of the notes could be improved. I used the YES_NO and tested with the advanced and the normal editor in staff detail and result pages. Could it be your XSLT files are custom and outdated? (ours were...) I'm on master using Koha testing docker, so those should be up to date. Here's the relevant bit from MARC21slim2intranetResults.xsl (line 285): <!-- Indicate if record is suppressed in OPAC --> <xsl:if test="$OpacSuppression = 1"> <xsl:if test="marc:datafield[@tag=942][marc:subfield[@code='n'] = '1']"> <span class="results_summary suppressed_opac">Suppressed in OPAC</span> </xsl:if> </xsl:if> Katrin, is that the same file you're using? Yes, I am using default - freshly set up database without any changes. What's your authorised value? I wonder about this line: [marc:subfield[@code='n'] = '1']"> I would have expected != ''. But YES_NO is 0 or 1 so that makes sense. Are you using other values by chance? OpacSuppression activated? Oop, there's the issue. OpacSuppression wasn't turned on in my testing docker. That's so standard for us that I forget it's off by default. So this does work in both master and 19.11. Also, agreed that !=0 would be a better check for suppression, but I'm not certain the query builder isn't looking for 1 specifically. That's a whole other bug I'm hoping to get around to filing and working on. I've just confirmed that this problem exists in master and 20.05. To recreate: - set OpacSuppression to Hide - Edit a bib, set 942$n=1 - confirm bib shows "Suppressed in OPAC" in the intranet and will not open on OPAC - Edit the framework used by this bib, connect the 942$n to the YES_NO auth value - Reload the bib without editing it, confirm "Suppressed in OPAC" message no longer shows - try to open record in OPAC, confirm it's still suppressed - edit record, set 942$n to No, confirm no apparent change on intranet, record now opens on opac - edit record, set 942$n to Yes, confirm no apparent change on intranet, record is now suppressed on opac - Edit the framework again, unlink the auth value - reload bib without editing, confirm bib shows "Suppressed in OPAC" in the intranet and will not open on OPAC Created attachment 120213 [details] [review] Bug 23406: Test for 1 or 'Yes' in record suppression In marc21 we now link the 942$n to 'YES_NO' authorised values. When displaying the details page in the staff client the authorised values in a record are translated before parsing the record with XSLT The '1' for YES_NO is translated to 'Yes' - we simply need to test for this additional value in the XSLT to ensure we display the suppression message To test: 1 - Confirm 952$n in default framework is tied ot authorised value 'YES_NO' or do so 2 - Set OpacSuppression to 'Hide' 3 - Edit a record in the default template, changing 942$n to 'Yes' 4 - Confirm the record is suppressed in opac 5 - Note there is no suppression notice in the record in staff client 6 - Apply patch 7 - Reload and confirm staff side shows suppression notice 8 - Confirm record still suppressed in OPAC 9 - Edit record, set 942$n to 'no' 10 - Confirm there is no suppression notice in staff client 11 - Confirm you can view the record in OPAC Created attachment 120719 [details] [review] Bug 23406: Test for 1 or 'Yes' in record suppression In marc21 we now link the 942$n to 'YES_NO' authorised values. When displaying the details page in the staff client the authorised values in a record are translated before parsing the record with XSLT The '1' for YES_NO is translated to 'Yes' - we simply need to test for this additional value in the XSLT to ensure we display the suppression message To test: 1 - Confirm 952$n in default framework is tied ot authorised value 'YES_NO' or do so 2 - Set OpacSuppression to 'Hide' 3 - Edit a record in the default template, changing 942$n to 'Yes' 4 - Confirm the record is suppressed in opac 5 - Note there is no suppression notice in the record in staff client 6 - Apply patch 7 - Reload and confirm staff side shows suppression notice 8 - Confirm record still suppressed in OPAC 9 - Edit record, set 942$n to 'no' 10 - Confirm there is no suppression notice in staff client 11 - Confirm you can view the record in OPAC Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> I am sorry, but I don't believe this is a good solution. This will fail the second someone translates the authorised value (trust me, we do that! :) ) Looking at this, I wonder if we should handle this differently: We run into this issue because as soon as something is linked to an authorised value, the code will be replaced by the description in the XSLT. And this should not happen: XSLT.pm (see bug 14377): + # Replace the field value with the authorised value *except* for MARC21/NORMARC field 942$n (suppression in opac) if ( !( $tag eq '942' && $subfield eq 'n' ) || $marcflavour eq 'UNIMARC' ) { $value = GetAuthorisedValueDesc( $tag, $letter, $value, '', $tagslib ) So even when linked to an authorised value, we should still be seeing a 1 and the check should be working. Please check why this is not working as expected. I also feel like the depends on bug 26116 is wrong here - should be a blocks. Created attachment 120772 [details] [review] Bug 23406: Unit test Created attachment 120773 [details] [review] Bug 23406: Don't translate suppressed authorised values We have a test in C4/XSLT/transformMARCXML4HTML which is meant to exclude the 942n, however, it doesn't work because it checks the $subfield parameter against n $subfield is an arrayref with the code and value as members we need to check $subfield->[0] To test: 1 - Apply only unit tests 2 - prove -v t/db_dependent/XSLT.t 3 - It fails 4 - Confirm 952$n in default framework is tied ot authorised value 'YES_NO' or do so 5 - Set OpacSuppression to 'Hide' 6 - Edit a record in the default template, changing 942$n to 'Yes 7 - Confirm the record is suppressed in opac 8 - Note there is no suppression notice in the record in staff client 9 - Apply second patch 10 - Reload and confirm staff side shows suppression notice 11 - Confirm record still suppressed in OPAC 12 - Edit record, set 942$n to 'no' 13 - Confirm there is no suppression notice in staff client 14 - Confirm you can view the record in OPAC 15 - prove -v t/db_dependent/XSLT.t 16 - Tests pass! Created attachment 120803 [details] [review] Bug 23406: Unit test Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> Created attachment 120804 [details] [review] Bug 23406: Don't translate suppressed authorised values We have a test in C4/XSLT/transformMARCXML4HTML which is meant to exclude the 942n, however, it doesn't work because it checks the $subfield parameter against n $subfield is an arrayref with the code and value as members we need to check $subfield->[0] To test: 1 - Apply only unit tests 2 - prove -v t/db_dependent/XSLT.t 3 - It fails 4 - Confirm 952$n in default framework is tied ot authorised value 'YES_NO' or do so 5 - Set OpacSuppression to 'Hide' 6 - Edit a record in the default template, changing 942$n to 'Yes 7 - Confirm the record is suppressed in opac 8 - Note there is no suppression notice in the record in staff client 9 - Apply second patch 10 - Reload and confirm staff side shows suppression notice 11 - Confirm record still suppressed in OPAC 12 - Edit record, set 942$n to 'no' 13 - Confirm there is no suppression notice in staff client 14 - Confirm you can view the record in OPAC 15 - prove -v t/db_dependent/XSLT.t 16 - Tests pass! Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> Awesome! Thx for the quick alternate patch! Created attachment 120807 [details] [review] Bug 23406: Unit test Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 120808 [details] [review] Bug 23406: Don't translate suppressed authorised values We have a test in C4/XSLT/transformMARCXML4HTML which is meant to exclude the 942n, however, it doesn't work because it checks the $subfield parameter against n $subfield is an arrayref with the code and value as members we need to check $subfield->[0] To test: 1 - Apply only unit tests 2 - prove -v t/db_dependent/XSLT.t 3 - It fails 4 - Confirm 952$n in default framework is tied ot authorised value 'YES_NO' or do so 5 - Set OpacSuppression to 'Hide' 6 - Edit a record in the default template, changing 942$n to 'Yes 7 - Confirm the record is suppressed in opac 8 - Note there is no suppression notice in the record in staff client 9 - Apply second patch 10 - Reload and confirm staff side shows suppression notice 11 - Confirm record still suppressed in OPAC 12 - Edit record, set 942$n to 'no' 13 - Confirm there is no suppression notice in staff client 14 - Confirm you can view the record in OPAC 15 - prove -v t/db_dependent/XSLT.t 16 - Tests pass! Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Pushed to master for 21.05, thanks to everybody involved! Pushed to 20.11.x for 20.11.06 Pushed to 20.05.x for 20.05.12 Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed. |