Feature Request/Idea: Allow creation of 'invisible' or 'internal' metadata

[Falco-KUB]

Overview of the Feature Request
Allow administrators to create metadata templates with optional or mandatory metadata fields for users to add metadata that will not become visible on the dataset's landing page upon publication. Those metadata should only be visible to administrators and/or through the API.

Request based on this discussion:
https://groups.google.com/g/dataverse-community/c/sXTNPfDCJS4/m/SP3lB2YlBAAJ

What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
Mainly (sub) dataverse administrators.

What inspired the request?
We are looking for some way of 'flagging' datasets for future administrative purposes. Something like:

• A copy of the metadata of this dataset should be sent to...
• A copy of the whole dataset should be sent to...
• This dataset should be updated when...

There might be different ways of achieving this, but we think that 'invisible' metadata fields would be easiest. This would also allow for adding 'internal comments' to a dataset.

What existing behavior do you want changed?

Any brand new behavior do you want to add to Dataverse?
New property for metadata fields.

Any related open or closed issues to this feature request?

[pdurbin]

@Falco-KUB thanks for opening this issue.

We are looking for some way of 'flagging' datasets for future administrative purposes.

For now, you might want to try curation labels for this: https://guides.dataverse.org/en/5.12.1/installation/config.html#allowedcurationlabels

[Falco-KUB]

Thanks. We would need 'post-publication' labels, though.

[Asbjoedt]

A temporary workaround for this can be to add this to your custom-stylesheet.css.

#NAME_OF_DATASETFIELD {
    display: none;
}

i.e.

#subject {
    display: none;
}

This will hide the field when viewing the dataset, but still make the field available when editing the datatset.

Note, this would technically not protect fields from being exposed to the public/user and in the case of fields with sensitive information, it should not be used.

[qqmyers]

FWIW: Dataverse has so far kept all metadata fields public - on principle and to avoid having to manage that in the UI, in exports, etc.
One recent option for handling metadata that shouldn't be user editable is the idea of protected metadata blocks - blocks that can only be edited via API with a secret key. These were developed by/for DANS for use cases related to the ones here. Protected blocks don't show up in the editing UI and having the metadata in a separate block, which starts out collapsed, hides it somewhat in view mode, but doesn't make it non-public.

[pdurbin]

Related:

• Feature Request/Idea: Allow creation of 'invisible' or 'internal' metadata #9209
• Feature Request: ability to restrict editing of certain metadata fields #10986

[cmbz]

2025/02/10

• During prioritization review we discussed getting additional Community feedback (esp. from other generalist repositories)
• Possibility of support for non-discovery-related administrative metadata?

[pdurbin]

Dataverse has so far kept all metadata fields public

Not anymore! There's an experimental feature coming in Dataverse 6.11 called Locally FAIR Data! Here's the (already merged) pull request:

• Locally FAIR Data #12319

@Falco-KUB I don't think this will help with your use case though. It sounds like you want a mix of public and private metadata.