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.
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.