How to associate collection metadata fields with specific collection theme

[alex buckley]

Kia ora/Hello everyone,

My name is Alex Buckley. I am a developer based in New Zealand and am starting on my journey in DSpace development. I am writing to this mailing list to please seek your feedback and advice.

Desired functionality

My team and I would like to add new input fields to the collection forms in the DSpace Admin. These input fields would be a user-friendly way for librarians to be able to add content to a collection theme. For example:

- Header text

- Intro text

- Footer content

We would then save this inputted data in new metadata fields.

Development question

My question is, how would you recommend we associate data stored in these new metadata fields with specific themes?

i.e. if someone adds content into the header text metadata field for the Fisheries collection. How can we ensure that that header text is only displayed by the Fisheries theme (which is linked to the Fisheries collection in the DSpace Angular config.*.yml file)?

This enhancement is something that we would want to upstream in a pull request to DSpace, so others can also benefit from it.

Thanks so much in advance for your assistance.

Kind regards,

Alex

[DSpace Developers]

Hi Alex,

I don't know that I have any great answers for you. 

But, it does seem like you'll need to somehow store the name of the theme as part of the metadata field.  Maybe create a new metadata schema/field named something like "theme.[themeName].header" (e.g. theme.fisheries.header) to add to the Collection object?  Then you'd have to customize the UI code to check for those metadata fields based on which theme is currently enabled.

I did also want to warn that you'll have to make sure you are not opening yourself up for XSS attacks.  Anytime you let users add HTML in fields, there's a risk that someone can embed JavaScript (to perform an XSS attack).  Currently, DSpace is protecting itself against that in other metadata fields via some of the built-in Angular protections.  I *think* those protections should carry over to what you are trying to do, but you need to carefully test that (and make sure never to bypass what Angular is doing).  See also https://angular.dev/best-practices/security#preventing-cross-site-scripting-xss

Good luck, and hopefully others will share ideas if they have any additional suggestions.  You are also welcome to create an early draft Pull Request if you want more specific feedback on how to contribute back to DSpace (see also our https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines)

Tim

[alex buckley]

Thank you very much for that information and advice Tim, much appreciated.

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/5aaae1b5-bbe1-4fe2-9659-9d327a393710n%40googlegroups.com.