Bug 36123 - Hide 856$y when $u is missing
Summary: Hide 856$y when $u is missing
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-16 20:18 UTC by Esther Melander
Modified: 2024-03-12 21:02 UTC (History)
1 user (show)

See Also:
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 Esther Melander 2024-02-16 20:18:59 UTC
I tested this behavior on 23.05 and two test sites for 23.11.

To replicate:

1. Check the default framework and ensure the 856$u is visible in the OPAC and Staff Interface. Ensure the URL box is checked.
2. Find a record in the default framework.
3. Add a link like https://www.google.com to the 856$u and Google to the 856$y
4. View the record in the record detail view and the OPAC. Click the link to make sure it works.
5. Now edit the default framework and uncheck the box for OPAC visibility. Leave all other settings as is.
6. Look at the record in the OPAC again and see that the Online Resource and link is still showing. Click on the link and see that it returns an error page.
7. Look at the record in the Staff interface and click on the link and see it is successful.
8. Edit the default framework again. Uncheck the box for Staff visibility and check the box for URL.
9. Click on the URL in the Staff Interface and the link works.
10. Edit the default framework and leave the visibility for the Staff Interface unchecked and uncheck the box for URL.
11. Test the link again in the staff interface and see the link is visible and works.

A combination of checking/unchecking visibility boxes and the URL box seems to result in inconsistent behavior. Disabling the URL sometimes returns an error page, sometimes does not. Most concerning is the visibility, which is being completely ignored. In some cases, it is preferable to hide the URL in the OPAC and still have it visible in the Staff Interface with a working link.

There are two current work arounds:

1. Disable the URL so that the link returns an error (though one could hover over the link and see what it is) which doesn't work consistently.
2. Removing the URL from the record seems to be the only way to not display the URL in the OPAC, but that also removes it from the staff interface.

I would expect the 856$u to not be visible if the OPAC or Staff visibility was unchecked.
Comment 1 Katrin Fischer 2024-02-18 12:10:15 UTC
Hi Esther, have you hidden $y in the OPAC as well?

I believe $u was removed, but the link was still built with $y as the text - that would explain why the link broke.
Comment 2 Esther Melander 2024-02-20 18:40:28 UTC
If $u is hidden, should $y appear in the OPAC as a clickable link (especially if the URL box is unchecked)? The link will be broken and return an error page, but should it even appear in the first place? I would think that if $u is hidden, $y should either be hidden automatically as well or only appear as text.
Comment 3 Katrin Fischer 2024-03-12 21:02:10 UTC
(In reply to Esther Melander from comment #2)
> If $u is hidden, should $y appear in the OPAC as a clickable link
> (especially if the URL box is unchecked)? The link will be broken and return
> an error page, but should it even appear in the first place? I would think
> that if $u is hidden, $y should either be hidden automatically as well or
> only appear as text.

We could make it more clever like that, but I think that makes it a different kind of bug. The problem is that the logic in our XSLT could be smarter, but the visibility settings work as expected.
$u is hidden when set to hidden, $y is kept. there are no relationships/dependencies between the subfields in the frameworks. I am changing the bug description a little bit to reflect that.