Make customized metadata block as "Required"

65 views
Skip to first unread message

Yan Na Cheng

unread,
May 20, 2026, 2:37:16 AMMay 20
to Dataverse Users Community
Hi all!

We created customized metadata block (CityUHK Metadata)  , and we want to make it "Required" and disable users to uncheck it (as same as citation metadata)
I tried to edit dataverse.xhtml but it only can visually (not functionally) make it disabled for editing.  Could please advice how I can set it up? Thank you!
Snag_6a9ecbd7.png


N.B.
1. Our Dataverse version is v. 6.8 build 1994-92d1ec8
2. Solr version is 9.8.0

Regards,
Joanna Cheng

Julian Gautier

unread,
May 20, 2026, 10:18:48 AMMay 20
to Dataverse Users Community
Hi Joanna,

Could you share a copy of the CityUHK Metadata TSV file?

I'm wondering what you have in the "required" column, if adding TRUE in that column for all fields will help, or if there's anything unexpected about the TSV file that's not making it work how we would expect.

All best,
Julian

Julian Gautier (he/him)
Product Research Specialist, IQSS
Interested in helping test Dataverse? Sign up for user experience research

Yan Na Cheng

unread,
May 20, 2026, 9:05:24 PMMay 20
to Dataverse Users Community
Hi Julian, 

Thank you for replying my message. You may find the screen cap of CityUHK Metadata tsv file below.  Actually not all fields were set as "Required = TRUE " because not all fields are mandatory in norm.
  2026-05-21_8-56-23.png

 For the datavese citation metadata block (below) , there are some fields which are set as "Required = FALSE" so i think it is not the root reasons to make citation metadata block disabled for checking.
2026-05-21_9-02-07.png

Regards,
Joanna Cheng

Julian Gautier

unread,
May 21, 2026, 2:21:01 PMMay 21
to Dataverse Users Community
Ah, I understand more now. Thanks!

You're right. It looks like in the design of the Dataverse TSV file, the "required" column more specifically means that users creating and editing datasets will have to fill the required field as long as the metadata block is enabled in the collection. And I think we've always assumed that if the metadata block contains any required fields, the person managing the collections will enable the metadata block, or won't disable it, since they'd want people to fill the required fields.

That seems to not be true in your case, right? Have folks who manage collections in the CUHK Research Data Repository disabled this metadata block? Or if that hasn't happened yet, do you think that they might disable it, and you want to prevent that from happening?

Yan Na Cheng

unread,
May 25, 2026, 10:31:38 PMMay 25
to Dataverse Users Community
Dear Julian,

I see the general assumption. We want to ensure that users are completely prevented from disabling this metadata block, whether by accident or intentionally. Could you advise if there are any reliable methods to achieve this?

Regards,
Joanna Cheng

Julian Gautier

unread,
Jun 2, 2026, 11:49:05 AM (11 days ago) Jun 2
to Dataverse Users Community
Hi Joanna Cheng,

Sorry for the late reply here. I was on vacation and just now catching up :)

Here are a few options I can think of right away, although they might not work for you and your users:
  • Give your users the "Curator" role on the collections, or create a role for them that doesn't include the "EditDataverse" permission. Then they won't be able to edit the collections at all, including disabling metadata blocks.
  • Make sure all collections already created by your users have the new metadata block enabled, create collections for your users and enable the metadata block, and monitor if any users disable the metadata block. If users do disable the metadata block, you'd have more evidence that more needs to be done to make sure that users don't disable it, and can use that evidence to justify other approaches.
  • Experiment with dataset metadata templates. It might be possible to create a template that includes the metadata block, then set that template as the default template for all collections, so that when users create datasets in those collections, the deposit form includes that metadata block. I don't have a lot of experience with templates so I'm not sure how good of a solution this is, such as if collection managers can and would likely remove the templates, disable the metadata block anyway, or other general user experience considerations with this approach.
  • Move the new fields into the Citation metadata block, which your users already cannot disable in their collections. This probably would involve a fair amount of development work for you and your colleagues, and you would have to maintain the forked Citation metadata block as you upgrade to newer versions of Dataverse. Also, I see a field in the CityUHK Metadata block about funding that seems similar to the Citation metadata block's "Funding Information" fields. I imagine you'd have to consider if having both fields on the same deposit form page would help or confuse users.
  • Propose that we revisit the logic about how Dataverse lets collection managers enable and disable metadata blocks. This would involve some research, design and development work on the Dataverse software. I would love to help with the research to inform the design and development, but I highly suspect that my colleagues and I at Harvard would not contribute to this sort of work until the Modern version of Dataverse has replaced the "JSF" or "Classic" version that we're all using, since we've been postponing a lot of this sort of work to focus on the Modern version of Dataverse. More info about the Modern version is at https://dataverse.harvard.edu/modern/featured-item/harvard/1. Lastly, Jim Myers also did a lot of work recently documenting how permissions work in Dataverse for different types of users, as he's helping figure out how to help installation and collection managers better control who has permission to do what. I'm still looking for where Jim wrote about his work, to see if and how our discussion here fits. If I find it I'll post the link in this thread.
In any case, thanks for raising this issue and for your patience! Let us know what you think!
Reply all
Reply to author
Forward
0 new messages