[Bug 36805] New: Separate OPACSearchForTitleIn content from markup
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 Bug ID: 36805 Summary: Separate OPACSearchForTitleIn content from markup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard@myacpl.org Reporter: oleonard@myacpl.org QA Contact: testopia@bugs.koha-community.org The OPACSearchForTitleIn system preference expects the user to be able to enter their list of links using the correct markup for them to be displayed in the "More searches" Bootstrap dropdown. As Bug 35844 shows, this content can get out of date with Bootstrap upgrades. I think we might want to separate the link content from the markup. My suggestion is that we ask the user to enter each link on one line, with URL pipe-separated from link text, e.g.: https://worldcat.org/search?q={TITLE}|Other Libraries (WorldCat) We can parse that in the template: [% FOREACH line IN OPACSearchForTitleIn.split('\n') %] [% part = line.split('\|') %] <a class="dropdown-item" href="[% part.first | html %]" target="_blank">[% part.last | html %]</a> [% END %] Does that sound reasonable? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It does... but then I know it will break some functionality that we have used OpacSearchForTitleIn for. It allows you to add other information at the moment using HTML/jQuery and the placeholders have proven useful to add the for example the Controlnumber in a parseable way. Maybe it would be nice to have another element that also allows to use the available placeholders/variables. A migration path might also be tricky? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #2 from Owen Leonard <oleonard@myacpl.org> --- Created attachment 169242 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169242&action=edit Bug 36805: (proof of concept) Markup-free OPACSearchForTitleIn implementation The updated default contents of OPACSearchForTitleIn would look like this: https://worldcat.org/search?q={TITLE}|Other Libraries (WorldCat) https://scholar.google.com/scholar?q={TITLE}|Other Databases (Google Scholar) https://www.bookfinder.com/search/?author={AUTHOR}&title={TITLE}&st=xl&ac=qr|Online Stores (Bookfinder.com) http://openlibrary.org/search/?author=({AUTHOR})&title=({TITLE})|Open Library (openlibrary.org) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #3 from Owen Leonard <oleonard@myacpl.org> --- (In reply to Katrin Fischer from comment #1)
I know it will break some functionality that we have used OpacSearchForTitleIn for.
I've attached a proof of concept to test if you're interested. I'm not sure I understand what functionality it would break.
A migration path might also be tricky?
Yes, and I haven't tried to figure it out. I'm not sure we can do anything automatically except maybe update the contents of the preference if it matches the default. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I don't want to block it because of our strange use case, but to explain: We have used it like a HTML customization basically, that is then moved into the right position using jQuery. As we use the CONTROLNUMBER and ISBN placeholders, it's not an easy move to a jQuery only solution. It would be nice if we had a HTML custumization with the ability to use this placeholders available on the datail page. Apart from "our problem" I think we need to think carefully how to communicate a possibly breaking change like this in a good way. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #5 from David Cook <dcook@prosentient.com.au> --- I noticed someone in bug 37573 using OPACSearchForTitleIn to inject <script> tags, which seems quite suboptimal to me. Sure, if you have access to update OPACSearchForTitleIn you'd also have access to OpacUserJS, so it's not a security vulnerability at this stage, but... as Owen says... I think separating functionality here is a good idea. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #4)
Apart from "our problem" I think we need to think carefully how to communicate a possibly breaking change like this in a good way.
At some stage, I'd love to just do 1 big breaking change where we say "all Javascript must be done via this one mechanism" and "all HTML inputs will now be scrubbed and limited to X, Y, Z elements/attributes". It'll be unpleasant as an upgrade, but from a security perspective it would be wise. Koha often errs on the side of convenience over security, and one day it may well come back to bite all of us. -- I figure breaking changes are OK for libraries with support, because they can get it fixed rapidly. They're harder for libraries without support, but... that's one of the reasons you have support, so that there is someone there to support you through changes. -- I think Owen's idea is a very good one. @Katrin, maybe for your use case we need to add a new HTML Customization that helps you out? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37573 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> ---
I think Owen's idea is a very good one. @Katrin, maybe for your use case we need to add a new HTML Customization that helps you out?
The main problem is that the other HTML customizations don't offer a way to add {CONTROLNUMBER}. We actually don't add JavaScript in there, just a hidden HTML element with that information in a parseable way. I could solve that via XSLT knowing in advance, maybe that's the easier way out of this. Having an area somewhere on the detail page for a custom HTML customization might still be a nice thing to have. I filed: Bug 37668 - Add HTML customization to OPAC detail page -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #8 from Owen Leonard <oleonard@myacpl.org> --- What if we added data attributes to the dropdown wrapper with the available placeholder data? <div id="moresearches_menu" data-author={} data-title={} etc. > -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, I think adding them might be nice, but if we change the way we do the OPACSearchForTitleIn, maybe another place would be more logical? I might misunderstand things! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #7)
I could solve that via XSLT knowing in advance, maybe that's the easier way out of this.
What do you mean by this? I've been doing XSLT magic lately so I might be able to help you out there... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to David Cook from comment #10)
(In reply to Katrin Fischer from comment #7)
I could solve that via XSLT knowing in advance, maybe that's the easier way out of this.
What do you mean by this?
I've been doing XSLT magic lately so I might be able to help you out there...
We use our own XSLT files for the detail page. My XSLT foo is OK for moving the invisible tag containing the 001 info into them for our specific use case. I am a bit weary of making those changes because it's used to integrate with a third party software, but it will just need some preparation/communication in the end. So taking our use case out of consideration - how can we communicate to libraries to adjust their settings after an update? Can we store the current settings somehow so they see what needs to be updated? ... Could we even attempt to parse the links and create the new structure? Probably to hard with SQL, but with Perl it might work? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #11)
So taking our use case out of consideration - how can we communicate to libraries to adjust their settings after an update? Can we store the current settings somehow so they see what needs to be updated?
... Could we even attempt to parse the links and create the new structure?
Probably to hard with SQL, but with Perl it might work?
Hmm that's a good point... I think it might be too hard. We might actually need to create a new system preference. We could remove the old one from the .pref file so that it just appears in Local Preferences, so that the data isn't lost... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I wonder how hard it would be to just parse the a tag. Getting a list of URLs from the href could be OK to do, description from the tags might be a little harder. But it could be worth while (saying as someone supporting over a 100 libraries... but admittedly can't provide a patch). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #13)
I wonder how hard it would be to just parse the a tag. Getting a list of URLs from the href could be OK to do, description from the tags might be a little harder. But it could be worth while (saying as someone supporting over a 100 libraries... but admittedly can't provide a patch).
Assuming well-formed HTML, a person probably could do a regex to just grab the "a" elements out of the current data. But that person also isn't going to be me. Personally, my goal for this preference is to just prevent security problems. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38321 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 Michał <schodkowy.omegi-0r@icloud.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schodkowy.omegi-0r@icloud.c | |om --- Comment #15 from Michał <schodkowy.omegi-0r@icloud.com> --- Okay I'll say something about my use-case and possible ways to support it without allowing HTML, then also about Katrin's use-case. Starting off with Katrin's use-case, I think actually the best solution would be for Koha templates for a biblio page to have some kind of script block where they'd set a global JS object with some extra metadata about the loaded up record (as in API for example), possibly even its whole MARC-in-JSON representation. This way any metadata would be accessible for whatever use-case there was there. Also I currently load the MARC data with API in JS to access extra metadata, so it'd let avoid doing that. Also some way for templates to refer to any MARC field possibly with some fallback (like mentioned XSLT) would probably satisfy some of the use-cases. My use-case involves flexibility, such as: - pulling some field out of MARC - changing the URL depending on whether MARC field is there or not (for example search by particular external control number or ID if it's there, otherwise search by ISBN if it's there with another URL, and otherwise either completely HIDE the link or fall back to title search for instance) Currently I just do a fetch of MARC from API and then update the links accordingly. If this was to be re-done to be a simpler field, it'd be nice to have some kind of id="" or class="" on the links settable, so that these fields can be referenced. Sure in worst case I could have a generic URL provided and match with a selector of a[href='...'], but that's a bit uglier I think? And having some metadata about biblio record in JS global object already would let me avoid said API request. Similar to Koha.i18n object right now. I could show my existing code when I'm at work again next week to maybe give a better idea of how it looks like currently for me. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org