[Bug 23406] New: Authorized Value for Suppression when added to Frameworks doesn't show Suppress in Staff Client
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Bug ID: 23406 Summary: Authorized Value for Suppression when added to Frameworks doesn't show Suppress in Staff Client Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: training@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #2 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- This appears to be fixed in 19.11. Haven't figured out what's causing it in 19.05 and previous. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |25335 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25335 [Bug 25335] Use of an authorised value in a marc subfield causes strict mode SQL error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- But it doesn't work in master, oddly enough. Also, adding a dependency where strict mode causes some trouble in addbiblio -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |minor -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #5 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #7 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|18.11 |19.05 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #8 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|25335 |26116 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25335 [Bug 25335] Use of an authorised value in a marc subfield causes strict mode SQL error https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26116 [Bug 26116] Allow multiple suppression values -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|19.05 |master --- Comment #9 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #10 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 120213 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120213&action=edit 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com Assignee|koha-bugs@lists.koha-commun |nick@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120213|0 |1 is obsolete| | --- Comment #11 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 120719 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120719&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Authorized Value for |When using an authorised |Suppression when added to |value for suppression, |Frameworks doesn't show |record doesn't show as |Suppress in Staff Client |suppressed in staff | |interface -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #13 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 120772 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120772&action=edit Bug 23406: Unit test -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #14 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 120773 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120773&action=edit 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! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120719|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|26116 | Blocks| |26116 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26116 [Bug 26116] Allow multiple suppression values -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120772|0 |1 is obsolete| | --- Comment #15 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 120803 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120803&action=edit Bug 23406: Unit test Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120773|0 |1 is obsolete| | --- Comment #16 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 120804 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120804&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #17 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Awesome! Thx for the quick alternate patch! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120803|0 |1 is obsolete| | --- Comment #18 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 120807 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120807&action=edit Bug 23406: Unit test Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #120804|0 |1 is obsolete| | --- Comment #19 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 120808 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120808&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |21.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 --- Comment #20 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Pushed to master for 21.05, thanks to everybody involved! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|21.05.00 |21.05.00,20.11.06 released in| | CC| |fridolin.somers@biblibre.co | |m Status|Pushed to master |Pushed to stable --- Comment #21 from Fridolin Somers <fridolin.somers@biblibre.com> --- Pushed to 20.11.x for 20.11.06 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable Version(s)|21.05.00,20.11.06 |21.05.00,20.11.06,20.05.12 released in| | --- Comment #22 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Pushed to 20.05.x for 20.05.12 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldstable |RESOLVED CC| |victor@tuxayo.net Resolution|--- |FIXED --- Comment #23 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org