Bug 23406

Summary: When using an authorised value for suppression, record doesn't show as suppressed in staff interface
Product: Koha Reporter: Kelly <training>
Component: CatalogingAssignee: Nick Clemens <nick>
Status: RESOLVED FIXED QA Contact: Testopia <testopia>
Severity: minor    
Priority: P5 - low CC: andrew, fridolin.somers, katrin.fischer, m.de.rooy, nick, phil, victor
Version: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Trivial patch
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
When cataloging records, the value of the 942$n if 1, Koha will suppress the record from the OPAC and also display a note on the staff client that this record is suppressed.  The system preference: OPACsuppression should be set to Hide.

To allow for more user-friendly cataloging, an authorized Value of Suppressed was created, the two values- 1- Suppress, 0 - Don't Suppress.  This authorized value was added to the default framework for the 943$n in Other Options.  Now when a cataloger wants to suppress a record when cataloging, they can have a drop-down menu to choose Suppress or Don't Suppress (versus remembering 1/0).  

Although this does work in suppressing the record from the OPAC, and when looking at the Marc Preview, the 942$n has the value 1, the staff client does not display a notification that this record is indeed suppressed.  

It would be nice if this process worked as regular suppression works- where this dropdown authorized value can be used and the note is visible in the staff client.
Comment 1 Katrin Fischer 2019-08-13 06:30:51 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)
Comment 2 Andrew Fuerste-Henry 2020-04-30 19:14:47 UTC
This appears to be fixed in 19.11. Haven't figured out what's causing it in 19.05 and previous.
Comment 3 Andrew Fuerste-Henry 2020-04-30 19:46:17 UTC
But it doesn't work in master, oddly enough. Also, adding a dependency where strict mode causes some trouble in addbiblio
Comment 4 Katrin Fischer 2020-04-30 21:33:40 UTC
(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...)
Comment 5 Andrew Fuerste-Henry 2020-05-01 11:56:42 UTC
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?
Comment 6 Katrin Fischer 2020-05-01 12:38:54 UTC
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?
Comment 7 Andrew Fuerste-Henry 2020-05-01 12:58:22 UTC
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.
Comment 8 Andrew Fuerste-Henry 2020-05-01 12:59:37 UTC
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.
Comment 9 Andrew Fuerste-Henry 2021-04-20 14:22:28 UTC
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
Comment 10 Nick Clemens 2021-04-27 12:30:48 UTC
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
Comment 11 Phil Ringnalda 2021-05-07 19:00:05 UTC
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>
Comment 12 Katrin Fischer 2021-05-09 13:19:54 UTC
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.
Comment 13 Nick Clemens 2021-05-10 12:19:57 UTC
Created attachment 120772 [details] [review]
Bug 23406: Unit test
Comment 14 Nick Clemens 2021-05-10 12:20:01 UTC
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!
Comment 15 Phil Ringnalda 2021-05-10 18:21:42 UTC
Created attachment 120803 [details] [review]
Bug 23406: Unit test

Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Comment 16 Phil Ringnalda 2021-05-10 18:21:46 UTC
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>
Comment 17 Katrin Fischer 2021-05-10 20:23:55 UTC
Awesome! Thx for the quick alternate patch!
Comment 18 Katrin Fischer 2021-05-10 20:32:17 UTC
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>
Comment 19 Katrin Fischer 2021-05-10 20:32:21 UTC
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>
Comment 20 Jonathan Druart 2021-05-11 13:39:15 UTC
Pushed to master for 21.05, thanks to everybody involved!
Comment 21 Fridolin Somers 2021-05-12 15:20:00 UTC
Pushed to 20.11.x for 20.11.06
Comment 22 Andrew Fuerste-Henry 2021-05-25 13:28:27 UTC
Pushed to 20.05.x for 20.05.12
Comment 23 Victor Grousset/tuxayo 2021-05-25 14:44:06 UTC
Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed.