Bug 31123

Created attachment 140345 [details] [review]
Bug 31123: Add `ContentWarningField` preference

This patch adds a new `ContentWarningField` preference allowing the
library to define which 59X field to use to store harmful content
warning notes.

Created attachment 140346 [details] [review]
Bug 31123: Display content warnings on the intranet

This patch adds handling to our XSLT processing to pass the new
`ContentWarningField` preference value to the stylesheets and then uses
that variable to add content warning notes to both the detail and search
result displays of the staff client.

Test plan
1) Run the database update to expose the new system preference
2) Set `ContentWarningField` to something sensible, like `599`
3) Add the above select field to one of your frameworks with a subfield
   `a`.
4) Edit a record with that framework to add a content warning into the
   record
5) Search for the record and confirm you now see `Content warning: Your
   test text`
6) Click into the record detail and confirm you see the content warning
   text there too
7) Bonus points: Assign a new authorized value category to the chosen
   field and subfield and confirm the staff client display text is used
   in the above tests.

Created attachment 140347 [details] [review]
Bug 31123: Display content warnings in OPAC

This patch adds handling of content warning display to the OPAC for both
detail and search result views

Test plan
1) Work through the test plan for the previous patch
2) Confirm that the same text now also displays on the equivilent OPAC
   pages.

OK.. so this patchset just allows for adding the designated content_warning fields to display on OPAC and Staff interfaces without having to customise your local XSLT stylesheets.

The 'quick add' functionality is still a work in progress and is likely to move to it's own bug now.

Created attachment 140356 [details] [review]
Bug 31123: Add `ContentWarningField` preference

This patch adds a new `ContentWarningField` preference allowing the
library to define which 59X field to use to store harmful content
warning notes.

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

Created attachment 140357 [details] [review]
Bug 31123: Display content warnings on the intranet

This patch adds handling to our XSLT processing to pass the new
`ContentWarningField` preference value to the stylesheets and then uses
that variable to add content warning notes to both the detail and search
result displays of the staff client.

Test plan
1) Run the database update to expose the new system preference
2) Set `ContentWarningField` to something sensible, like `599`
3) Add the above select field to one of your frameworks with a subfield
   `a`.
4) Edit a record with that framework to add a content warning into the
   record
5) Search for the record and confirm you now see `Content warning: Your
   test text`
6) Click into the record detail and confirm you see the content warning
   text there too
7) Bonus points: Assign a new authorized value category to the chosen
   field and subfield and confirm the staff client display text is used
   in the above tests.

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

Created attachment 140358 [details] [review]
Bug 31123: Display content warnings in OPAC

This patch adds handling of content warning display to the OPAC for both
detail and search result views

Test plan
1) Work through the test plan for the previous patch
2) Confirm that the same text now also displays on the equivilent OPAC
   pages.

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

I have signed off, but noted that when using authorized values the authorized value code is displayed in the OPAC and staff interface, but not the text from the descriptions.

(In reply to David Nind from comment #8)
> I have signed off, but noted that when using authorized values the
> authorized value code is displayed in the OPAC and staff interface, but not
> the text from the descriptions.

Hi Martin, could you have a look at this, before we continue here?

Interesting, I can't replicate that issue.. perhaps caching related?

We don't really touch any of the AV in XSLT handling code in here, so I can't see how it would fail here but not elsewhere?

(In reply to Martin Renvoize from comment #10)
> Interesting, I can't replicate that issue.. perhaps caching related?

It was some sort of caching issue - apologies for the false alarm!

I retested again, and then did a flush_memcached, restart_all, and cleared the browser cache - the descriptions for the authorised values now display instead of the authorised value codes.

Awesome, thanks for retesting David :)

Hi Martin, 

I have questions :)

Can you how you chose the subfields? Will this be documented somewhere, maybe in the pref?

It looks like $z is displayed first, separated by a space and then followed by abcdefgijklnou, but this is not a "complete" list of subfields either. 

+                    <xsl:when test="marc:subfield[@code='z']">
+                        <xsl:value-of select="marc:subfield[@code='z']"/><xsl:text> </xsl:text>
+                    </xsl:when>
+                    <xsl:otherwise>
+                        <xsl:call-template name="subfieldSelect">
+                            <xsl:with-param name="codes">abcdefgijklnou</xsl:with-param>
+                        </xsl:call-template>
+                    </xsl:otherwise>
+                </xsl:choose>

Failing, but just to get your attention, overall this looks good.

I think my choice of subfields and z was a bit arbitrary.. I used the 'action note', 583, as a basis.

Happy to be guided.

Subfield `z` is often 'public note' and subfield `x` is often 'nonpublic note' for other fields.. I did wonder about supporting subfield `u` specifically for a 'uri' to allow for linking to more details or a content policy or some such.

(In reply to Martin Renvoize from comment #16)
> Subfield `z` is often 'public note' and subfield `x` is often 'nonpublic
> note' for other fields.. I did wonder about supporting subfield `u`
> specifically for a 'uri' to allow for linking to more details or a content
> policy or some such.

a, x an z certainly make sense. Not sure what is better: keep it simple or make it a complete list. Both could be options.

The 5xx vary a lot in the number of subfields, 500 for example has almost none/just the basics: https://www.loc.gov/marc/bibliographic/bd500.html

Created attachment 143880 [details] [review]
Bug 31123: Add `ContentWarningField` preference

This patch adds a new `ContentWarningField` preference allowing the
library to define which 59X field to use to store harmful content
warning notes.

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

Created attachment 143881 [details] [review]
Bug 31123: Display content warnings on the intranet

This patch adds handling to our XSLT processing to pass the new
`ContentWarningField` preference value to the stylesheets and then uses
that variable to add content warning notes to both the detail and search
result displays of the staff client.

Test plan
1) Run the database update to expose the new system preference
2) Set `ContentWarningField` to something sensible, like `599`
3) Add the above select field to one of your frameworks with a subfield
   `a`.
4) Edit a record with that framework to add a content warning into the
   record
5) Search for the record and confirm you now see `Content warning: Your
   test text`
6) Click into the record detail and confirm you see the content warning
   text there too
7) Bonus points: Assign a new authorized value category to the chosen
   field and subfield and confirm the staff client display text is used
   in the above tests.

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

Created attachment 143882 [details] [review]
Bug 31123: Display content warnings in OPAC

This patch adds handling of content warning display to the OPAC for both
detail and search result views

Test plan
1) Work through the test plan for the previous patch
2) Confirm that the same text now also displays on the equivilent OPAC
   pages.

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

(In reply to Katrin Fischer from comment #17)
> (In reply to Martin Renvoize from comment #16)
> > Subfield `z` is often 'public note' and subfield `x` is often 'nonpublic
> > note' for other fields.. I did wonder about supporting subfield `u`
> > specifically for a 'uri' to allow for linking to more details or a content
> > policy or some such.
> 
> a, x an z certainly make sense. Not sure what is better: keep it simple or
> make it a complete list. Both could be options.
> 
> The 5xx vary a lot in the number of subfields, 500 for example has almost
> none/just the basics: https://www.loc.gov/marc/bibliographic/bd500.html

Rebased. Suggestion: let's use a complete list? That way libraries can use whatever. Also maybe good in case of UNIMARC?

Did a tiny rebase: conflict in .pref

Created attachment 147342 [details] [review]
Bug 31123: Add `ContentWarningField` preference

This patch adds a new `ContentWarningField` preference allowing the
library to define which 59X field to use to store harmful content
warning notes.

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

Created attachment 147343 [details] [review]
Bug 31123: Display content warnings on the intranet

This patch adds handling to our XSLT processing to pass the new
`ContentWarningField` preference value to the stylesheets and then uses
that variable to add content warning notes to both the detail and search
result displays of the staff client.

Test plan
1) Run the database update to expose the new system preference
2) Set `ContentWarningField` to something sensible, like `599`
3) Add the above select field to one of your frameworks with a subfield
   `a`.
4) Edit a record with that framework to add a content warning into the
   record
5) Search for the record and confirm you now see `Content warning: Your
   test text`
6) Click into the record detail and confirm you see the content warning
   text there too
7) Bonus points: Assign a new authorized value category to the chosen
   field and subfield and confirm the staff client display text is used
   in the above tests.

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

Created attachment 147344 [details] [review]
Bug 31123: Display content warnings in OPAC

This patch adds handling of content warning display to the OPAC for both
detail and search result views

Test plan
1) Work through the test plan for the previous patch
2) Confirm that the same text now also displays on the equivilent OPAC
   pages.

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

Created attachment 147345 [details] [review]
Bug 31123: Update Staff XSLT to include all subfields

This patch updates the XSLT sheets to include all subfields in your
selected ContentWarningField in display and handles converting the
subfield u if present to a hyperlink.

Created attachment 147346 [details] [review]
Bug 31123: Add all subfields to OPAC stylsheet

This patch updates the OPAC XSLT's to display all subfields, barring the
'x' field which is often used as a 'private note' in other notes fields.

We also handle converting subfield 'u' to a hyper link if it's found to
be present and use subfield 'a' for the link text if present.

Created attachment 148992 [details] [review]
Bug 31123: Add `ContentWarningField` preference

This patch adds a new `ContentWarningField` preference allowing the
library to define which 59X field to use to store harmful content
warning notes.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 148993 [details] [review]
Bug 31123: Display content warnings on the intranet

This patch adds handling to our XSLT processing to pass the new
`ContentWarningField` preference value to the stylesheets and then uses
that variable to add content warning notes to both the detail and search
result displays of the staff client.

Test plan
1) Run the database update to expose the new system preference
2) Set `ContentWarningField` to something sensible, like `599`
3) Add the above select field to one of your frameworks with a subfield
   `a`.
4) Edit a record with that framework to add a content warning into the
   record
5) Search for the record and confirm you now see `Content warning: Your
   test text`
6) Click into the record detail and confirm you see the content warning
   text there too
7) Bonus points: Assign a new authorized value category to the chosen
   field and subfield and confirm the staff client display text is used
   in the above tests.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 148994 [details] [review]
Bug 31123: Display content warnings in OPAC

This patch adds handling of content warning display to the OPAC for both
detail and search result views

Test plan
1) Work through the test plan for the previous patch
2) Confirm that the same text now also displays on the equivilent OPAC
   pages.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 148995 [details] [review]
Bug 31123: Update Staff XSLT to include all subfields

This patch updates the XSLT sheets to include all subfields in your
selected ContentWarningField in display and handles converting the
subfield u if present to a hyperlink.

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 148996 [details] [review]
Bug 31123: Add all subfields to OPAC stylsheet

This patch updates the OPAC XSLT's to display all subfields, barring the
'x' field which is often used as a 'private note' in other notes fields.

We also handle converting subfield 'u' to a hyper link if it's found to
be present and use subfield 'a' for the link text if present.

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 148997 [details] [review]
Bug 31123: Fix file permission

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Pushed to master for 23.05.

Nice work everyone, thanks!

Enhancement - not backporting to 22.11.x

Nice work everyone!