IQSS
custom JavaScript setting for metadata editing
What this PR does / why we need it: It allows loading a custom JavaScript for editing metadata.
Which issue(s) this PR closes:
Closes #8722
Is there a release notes update needed for this change?: Yes.
Additional documentation: For example, when you want a metadata field to be controlled by an external set of possible values that do not have translations or URIs, you can implement a simple lookup in a JavaScript. An example of a person name lookup from within an organization:
Coverage increased (+0.0003%) to 20.035% when pulling 39fa64d3dc1342c81b06402326813533695cd3e4 on ErykKul:8722_custom_javascript into c7b8b8237d5dd736b6aa504f4ea3e73775cab059 on IQSS:develop.
If all you want is to drop an arbitrary script on the page, perhaps adding it to a custom header or footer would work? FWIW: I did this in developing the ORCID script prior to the CVoc mechanism being in place.
@qqmyers I tried that, but that did not work as expected. The script's document.ready function needs to run to add the search button and attributes to the metadata input fields to attach the javascript to the DOM elements. With repeating fields like author, this has to happen each time a new entry is added.
When I loaded the javascript in the footer, I noticed that the ready function was only triggered when the user opens the dataset, but no more when changing to the metadata tab, nor when the user clicks 'Edit metadata'.
By using the javascript loading from the external vocabularies, it works, but that has some disadvantages (see the related issue).
@pdurbin
Some extra explanation about the location of the javascript and how it is used at KU Leuven:
We have a reverse proxy that manages relative paths. /covoc/ points to ruby server that also implements the business logic calls to our internal (KU Leuven) servers. Since everything is behind a reverse proxy, you can enforce same origin policies (CORS) at the browser, etc. Reverse proxy, dataverse, ruby server and some other servers (e.g., database) are then docker images served by one docker with internal network with only the reverse proxy being exposed directly. It is a nice architecture done by @Kris-LIBIS for us.
The specific script we want to load: /covoc/js/covoc.js has relative path to the reverse proxy where dataverse is hosted. For example, in our production it becomes: https://rdr.kuleuven.be/covoc/js/covoc.js (you can just click on the link to view it in the browser). Note that it uses relative paths itself, and it won't work for you without the covoc ruby backend deployed.
@ErykKul thanks! All the extra context helps a lot. I have no plans to deploy the Ruby backend, etc. 😄 I confirmed that when I use the new setting I can insert Javascript into the dataset page from a URL (to a Javascript file, of course).
Based on this, I'm approving this PR and sending it to QA.
Something for all of us to think about... we allow a custom CSS file (:StyleCustomizationFile). Should we allow a custom Javascript file (:JavascriptCustomizationFile?). Or multiple files? In practice, people tend to add Javascript files in a custom header or footer (as @qqmyers mentions above). This PR includes the extra Javascript on just the dataset page rather than all pages. @Kris-LIBIS mentioned above that the script didn't work in the footer so it seems like the need for this PR is real.
At standup I said I was happy enough with this PR to move it to QA but I'd like another set of eyes on it before we merge.
