Bug 38677 - XSLT doesn't follow framework's visibility settings
Summary: XSLT doesn't follow framework's visibility settings
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: 24.05
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-11 15:38 UTC by Lisette Scheer
Modified: 2025-04-23 21:31 UTC (History)
6 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lisette Scheer 2024-12-11 15:38:17 UTC
Users often assume the visibility checkbox on fields on the frameworks will change if it's visible on the OPAC details page. 

It would be great if we could build/update the XSLT based on those fields (or additional fields for details, search results, for both OPAC and Staff. 

This would be good for users being able to make changes without access to the XSLT.
Comment 1 Katrin Fischer 2024-12-11 16:12:46 UTC
Hi Lisette, can you explain this a bit more?

I believe the problem is, that you would have to write XSLT display rules for every available MARC field... or have something that is not XSLT people can adjust. As sequence and other rules apply to MARC it's probably not super easy to write something generic. We also need translatable labels, so can't pull them from database - and then the librarianese field names are probably not always best for users anyway.

And you also need to differentiate by views:
- Normal view: "don't display" works, "display" works if XSLT has any code to display the field.
- Labelled MARC: setting should work
- Plain MARC: setting should work

Maybe it could help to add a hint that the visibility settings only apply to the normal view in a limited way?
Comment 2 David Cook 2024-12-11 22:22:16 UTC
(In reply to Katrin Fischer from comment #1)
> Maybe it could help to add a hint that the visibility settings only apply to
> the normal view in a limited way?

That's probably the way to go. I had to explain that to a librarian the other day.

--

Personally, I wouldn't want libraries to be able to arbitrarily add fields to the display other than what is provided in the XSLT. They don't always think of the implications of HTML display when checking the checkboxes in the frameworks.

That said... I have been thinking of adding a collapsed "Other information" section which can show additional information beyond what we want shown in the more compact display. 

From a technical standpoint, we wouldn't necessarily have to build/update the XSLT. Rather, using XML::LibXSLT->register_function(), we could introduce a Perl function to the XSLT to tell us whether or not to render a particular field/subfield combination. (I do this all the time in our local Koha and in Koha plugins.)

I think the hard part would be knowing which fields are already handled by the XSLT and which aren't. I think that could get messy.

I can also imagine demands increasing. For instance, this could work for just showing the information *as recorded* in the MARC, but we wouldn't be able to render links or additional modifications without coding, which then leads to even more messiness I reckon...
Comment 3 Nick Clemens (kidclamp) 2024-12-16 11:38:20 UTC
(In reply to David Cook from comment #2)
> Personally, I wouldn't want libraries to be able to arbitrarily add fields
> to the display other than what is provided in the XSLT. They don't always
> think of the implications of HTML display when checking the checkboxes in
> the frameworks.

I'm not sure I understand the concern here, can you explain what the implications might be?
 
> From a technical standpoint, we wouldn't necessarily have to build/update
> the XSLT. Rather, using XML::LibXSLT->register_function(), we could
> introduce a Perl function to the XSLT to tell us whether or not to render a
> particular field/subfield combination. (I do this all the time in our local
> Koha and in Koha plugins.)

If you have an example or two of what you do here, that would be interesting


> I think the hard part would be knowing which fields are already handled by
> the XSLT and which aren't. I think that could get messy.
> 
> I can also imagine demands increasing. For instance, this could work for
> just showing the information *as recorded* in the MARC, but we wouldn't be
> able to render links or additional modifications without coding, which then
> leads to even more messiness I reckon...

These sound like future challenges, or opportunities, for development ;-)

It may be XSLT is not the best tool for what we want. We have largely stopped using custom XSLT in favor of using the API to pull extra fields from the MARC. Users with custom XSLT don't get any Koha enhancements that use the XSLT until an upgrade, and the process of rebasing XSLT can be quite tedious.

I think one of the things we really want from this is, users should be able to easily control which fields are displayed, without a great amount of technical knowledge. We find XSLT is a bit of a high bar, a bit too easy to make one change, and break the entire display :-)
Comment 4 David Cook 2024-12-16 23:30:23 UTC
(In reply to Nick Clemens (kidclamp) from comment #3)
> I'm not sure I understand the concern here, can you explain what the
> implications might be?

The concern would be in terms of UX. The scenario would be a library checks every MARC field they think that could be remotely useful, checks the display for 1 record, but misses a bunch of other records that now have overcrowded displays that aren't useful to end users. (I'm also thinking about overlap between chosen fields and ones that already exist in the XSLT.)

I can already imagine needing to routinely pare back the options that people have chosen.

That said, there are times where it would be nice to let a library add the display of some fields that they use that no other library uses. Maybe I'm just being too pessimistic. 
  
> > From a technical standpoint, we wouldn't necessarily have to build/update
> > the XSLT. Rather, using XML::LibXSLT->register_function(), we could
> > introduce a Perl function to the XSLT to tell us whether or not to render a
> > particular field/subfield combination. (I do this all the time in our local
> > Koha and in Koha plugins.)
> 
> If you have an example or two of what you do here, that would be interesting

Here's an example from a plugin. This is in the .pm code (declared near the top of the .pm file as it's a class function we want run at load time):
XML::LibXSLT->register_function("http://www.prosentient.com.au/xsltperl/jats","validate_isbn",\&_validate_isbn);
sub _validate_isbn {
    my ($input) = @_;
    my $rv = XML::LibXML::Boolean->False;
    if ($input){
        eval {
            my $isbn = Business::ISBN->new($input);
            if ($isbn && $isbn->is_valid){
                $rv = XML::LibXML::Boolean->True;
            }
        };
        if ($@){
            warn $@;
        }
    }
    return $rv;
}

Then in the XSLT in the xsl:stylesheet element, I add:
xmlns:pro="http://www.prosentient.com.au/xsltperl/jats"

And in the body of the XSLT:
<xsl:if test="pro:validate_isbn(marc:datafield[@tag='020'][1]/marc:subfield[@code='a'][1])">
<!-- Do stuff! -->
</xsl:if>

The main limit is our imaginations here. 

Also, keep in mind that Koha::XSLT::Base allows us to pass "parameters" to the transform() functions. While I initially thought about that in terms of passing a string which could be manipulated, it is XPath, so it could be easy to generate some XPath in Koha that lists all the extra fields/subfields that we want to display, and then use that for selecting within the XSLT.

Lots of options there using existing functionality available to us. 

> It may be XSLT is not the best tool for what we want. We have largely
> stopped using custom XSLT in favor of using the API to pull extra fields
> from the MARC. Users with custom XSLT don't get any Koha enhancements that
> use the XSLT until an upgrade, and the process of rebasing XSLT can be quite
> tedious.

Rebasing XSLT is one of my least favourite activities in work life. 

Using the API is a good plan. It's much more in the vein of what we're trying to do overall with Koha I reckon.
 
> I think one of the things we really want from this is, users should be able
> to easily control which fields are displayed, without a great amount of
> technical knowledge. We find XSLT is a bit of a high bar, a bit too easy to
> make one change, and break the entire display :-)

Generally speaking, I'm in favour of giving power to the people... except where it creates more issues than it reduces. 

I think I'd be much more in favour of this, if we had a way of controlling how much space the fields take up.