https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37573 --- Comment #5 from Michał <schodkowy.omegi-0r@icloud.com> ---
(Going back to the Javascript thing, really that should be in OpacUserJS. Also, one day in the future with Content-Security-Policy, this type of script injection won't work anymore. The script execution will be blocked by the browser.)
The thing is, as it stands, all the HTML fields/preferences in Koha allow using JavaScript, it goes way beyond OpacUserJS. Even the HTML templates for various parts of OPAC etc. In the big picture I kinda agree, but this will require changes all throughout Koha, with proper announcement as it's sure to break some existing setups. But for now we should fix the bug and inconsistency that happens today unintentionally.
This does sound like a bug, but personally I wouldn't want OPACSearchForTitleIn to be able to inject <script></script> tags either...
I should share my use case. I have a tag like this: <a href="https://worldcat.org/search?q={TITLE}" target="_blank">Other Libraries (WorldCat)<script>var openInWorldCatCurScript = document.currentScript;</script></a> <!-- document.currentScript.parentElement will then be our <a> tag --> And at the bottom (it doesn't set up the event listener right away, as we have two searches like this, so to avoid double API calls): <script> document.addEventListener('DOMContentLoaded', () => processOPACSearchForTitleIn({BIBLIONUMBER}, openInWorldCatCurScript)); </script> The JS func that's called accesses the MARC with the public API and extracts info such as direct WorldCat id if it exists, and then swaps the generic title search URL to a direct link to the record. I realize now that is kinda weird and technically I could've just used "id" attribute in HTML, since it won't be duplicated in the DOM due to nature of Koha and XHR loading not being used in this particular place. But...
I reckon Owen's idea at bug 36805 is a good way to go.
I kind of have another issue with this. Replacing this to be a very simple list of URLs would limit people to just the currently provided minimal templates, or they'd have to resort to using awkward CSS selectors in the JS. I guess it could work if one used TT templates only... To keep it being featureful, one should have access to any fields from MARC and conditional variables there. For example, with the search above in WorldCat, we want to change what kind of URL is shown based on whether custom field in MARC with the ID exists (we keep it somewhere in 9xx unfortunately, not in the standard field...). And in the second case, we want to see if a field exists in MARC and only then show the particular search URL. So the only ways to achieve it all would be either with JS, or with TT templates with full access to the MARC data of the record so that it wouldn't have to be fetched from REST API... -- You are receiving this mail because: You are watching all bug changes.