Multiple value in a child field

[Gepiro]

What steps does it take to reproduce the issue? If I had a new metadatablock inside my customized dataverse instance I need to have a big field with a lot of children fields. Some could have multiple values, but this does not work in two different ways.

• When does this issue occur?

1. If I have a child field associated with a vocabulary I can choose multiple values but I can visualize only the first one.
2. If I have a simple text child field but cannot choose more values for it.

• Which page(s) does it occurs on? Visualization and editing pages of datasets

• To whom does it occur (all users, curators, superusers)? All users, curators and superusers

• What did you expect to happen? I think that in both cases I need to have a field that allows users to upload more values

Which version of Dataverse are you using? 6.1

Screenshots:

Rows in the metadata block's TSV:

name	title	description	watermark	fieldType	displayOrder	displayFormat	advancedSearchField	allowControlledVocabulary	allowmultiples	facetable	displayoncreate	required	parent	metadatablock_id	termURI
formOfSupplySUSMirri	Form Of Supply	The forms of supply of the strain to users.		text	8		TRUE	TRUE	TRUE	FALSE	FALSE	FALSE	susmirri	unitoProjects
recommendedMediumGrowthSUSMirri	Recommended Medium Growth	The acronym of the growth medium.		text	9		TRUE	FALSE	TRUE	FALSE	FALSE	FALSE	susmirri	unitoProjects

Thank you for the help!

[DS-INRA]

Hello, this already has been traced here :

• 377

However maybe we should keep your issue for the screenshots that aren't in the former one :)

[pdurbin]

Hmm, @DS-INRA I love closing old issues in favor of new ones that are better written an have screenshots. 😄

However, I think of #377 as "support multiple author affiliations" (and other multiples of children).

This new issue covers that, I think but I'm confused why "Form of Supply" doesn't display anything but "Dry Ice;" ... it doesn't display the other values like "Lyo". Smells like a bug.

Either way, yes, when we estimate this and put it in a sprint we should consider both issues, I'd say.

[Gepiro]

I want to notify another problem. If I have a child field which is also a parent we obtain another bug and we cannot insert the children values.

Rows in the metadata block's TSV:

name	title	description	watermark	fieldType	displayOrder	displayFormat	advancedSearchField	allowControlledVocabulary	allowmultiples	facetable	displayoncreate	required	parent	metadatablock_id	termURI
testedTempGrowthRangeSUSMirri	Tested Temp Growth Range			none	16		FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	susmirri	unitoProjects
minTestedTempGrowthRangeSUSMirri	Minimum			int	0		FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	testedTempGrowthRangeSUSMirri	unitoProjects
maxTestedTempGrowthRangeSUSMirri	Maximum			int	1		FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	testedTempGrowthRangeSUSMirri	unitoProjects

[jggautier]

Hi @Gepiro. I've been passively following this conversation, saw your comment "If I have a child field which is also a parent", and just wanted to point out that Dataverse doesn't technically support the idea of a child field also being a parent field, although from what I can tell so far, the Dataverse guides never say this explicitly.

Maybe in the short term, we should add to the Metadata Customization Guide that child fields cannot have their own child fields. And in the long term we could consider changes to the UI to support this.

Another challenge of a big field with a lot of children fields is how the values entered in those fields are displayed. This is discussed in https://github.com/IQSS/dataverse/issues/6589 and other GitHub issues. The challenge comes up often enough that I've recommended that parent fields contain no more than 4 child fields and I've considered including this recommendation in our guidance about creating metadata blocks.

[pdurbin]

Dataverse doesn't technically support the idea of a child field also being a parent field

Correct. However, @vera and @johannes-darms are using them (please be careful!):

• 9200

@jggautier yes, I agree we should be more clear in the guides that grandchild fields are not supported.

[johannes-darms]

Dataverse doesn't technically support the idea of a child field also being a parent field

Correct. However, @vera and @johannes-darms are using them (please be careful!):

It works like a charm, we have not found any problem in this context from the beginning. Only the user interface does not support it, the API works perfectly. You just need to update the nested loops with recursion in the JSF codes.

[Gepiro]

Hi @Gepiro. I've been passively following this conversation, saw your comment "If I have a child field which is also a parent", and just wanted to point out that Dataverse doesn't technically support the idea of a child field also being a parent field, although from what I can tell so far, the Dataverse guides never say this explicitly.

Maybe in the short term, we should add to the Metadata Customization Guide that child fields cannot have their own child fields. And in the long term we could consider changes to the UI to support this.

Another challenge of a big field with a lot of children fields is how the values entered in those fields is displayed. This is discussed in #6589 and other GitHub issues. The challenge comes up often enough that I've recommended that parent fields contain no more than 4 child fields and I've considered including this recommendation in our guidance about creating metadata blocks.

I got it. Make sense.

At this point, I think that this is not a real problem, but that the bugs are the two explained at the top of this conversation (for the multiple values). Do you have some ideas on how to obtain a workaround for these problems or do I have to wait for some updates? Thanks for the help

[jggautier]

Hmmm, to avoid the two bugs listed in the first comment, as a workaround, would it be possible to redesign these metadata fields? For example, does the SUS-Mirri.IT field need to be a compound field? Will depositors using your Dataverse repository need to create multiple instances of that SUS-Mirri.IT compound field?

If depositors won't need to create multiple instances of that SUS-Mirri.IT compound field, could the 10 child fields can be parent fields instead? Then when depositors choose multiple values in the "Form of Supply" field's dropdown menu, those values will appear when viewing the metadata. And the "Recommended Medium Growth" field will include a plus button that depositors can click to create more "Recommended Medium Growth" fields where they can add more values, which will also appear when viewing the metadata.

[Gepiro]

Hmmm, to avoid the two bugs listed in the first comment, as a workaround, would it be possible to redesign these metadata fields? For example, does the SUS-Mirri.IT field need to be a compound field? Will depositors using your Dataverse repository need to create multiple instances of that SUS-Mirri.IT compound field?

If depositors won't need to create multiple instances of that SUS-Mirri.IT compound field, could the 10 child fields can be parent fields instead? Then when depositors choose multiple values in the "Form of Supply" field's dropdown menu, those values will appear when viewing the metadata. And the "Recommended Medium Growth" field will include a plus button that depositors can click to create more "Recommended Medium Growth" fields where they can add more values, which will also appear when viewing the metadata.

The problem is not that it could be more instances of SUS-MIRRI.IT field, but it is useful to divide these fields from the others. In future, we could add a lot of other compound fields at the same level as SUS-MIRRI.IT.

[jggautier]

Thanks @Gepiro. It's really helpful helpful to learn more about why you're trying to use compound fields this way. I agree that compound fields also let depositors see how a group of fields are related to each other. But I think we'd need to do work to update Dataverse so that it supports what you originally created this GitHub issue for and the related things we've written about.

More broadly speaking, I still think this is a case where we can do a better job of setting expectations about what Dataverse is and isn't currently capable of. It looks like Dataverse technically lets us load metadata blocks that have a parent field with many child fields, child fields with their own child fields, and child fields that accept multiple values. But maybe we should be more explicit in the User Guides that this isn't currently supported, especially if the user interface does not support it.

There's related discussion in the GitHub issue at https://github.com/IQSS/dataverse/issues/10688 about the idea of using tools that check the validity of metadata blocks as we're designing them and before we try to load them into Dataverse, and about updating Dataverse so that it fixes issues with the metadata blocks we're trying to load into Dataverse. And following what @poikilotherm wrote last week, maybe Dataverse should do more validating of the metadata block TSV files that folks try to load into Dataverse.

[HenningTimm]

For completeness' sake, I think this issue is tracking the same or a very similar problem:

• 9911

[poikilotherm]

One of our customers told me they are interested in the multi-affiliation use case for authors, as it is a common thing among their users to have two or more affiliations.

[jggautier]

Thanks @poikilotherm. Since you mentioned how users need Dataverse to better support users who want to add multiple affiliations to a single author, I should add that one of the designs that the UX working group is working on might satisfy this goal, although this use case isn't exactly in scope for the redesign. When we're ready, would you be interested in helping us get feedback from your customers?

And back in July I wrote that I thought our documentation should let folks know that Dataverse doesn't support multiple values in a child field and discourage other things that we've learned aren't well supported yet. Since then I've mentioned these things whenever I talk about the design of metadata in Dataverse, like during trainings and presentations. But I wonder if improving the documentation in this way would be in scope for the Dataverse documentation working group. @vaidap and @pdurbin, what do you think?

[pdurbin]

Yes, let's write it down please. A dedicated issue might be best.