Authority for document types is not stored in the authority field

[olli-gold]

Describe the bug
In DSpace CRIS 7 document types are based on the COAR controlled vocabulary. This means that entries in metadata field dc.type are related to a COAR document type ID (taken from the IDs in file publication-coar-types.xml). The COAR ID is managed in column authority of the metadatavalue table.

On DSpace-CRIS 2023.02.0x the authority value for document types (and probably other Dropdown menus of ControlledVocabulary) are not passed correctly, so they are not stored in the authority field metadatavalue.authority in the database.

To Reproduce
Steps to reproduce the behavior:

1. Edit an existing item (publication) - be sure to use COAR based controlled vocabulary
2. Choose a value from the document type dropdown
3. Check the database for the edited item - metadatavalue.authority will be empty

Expected behavior
The correct authority ID should be in field metadatavalue.authority.

Related work
Handling of Authority Values for Document Types within the migration procedure has been addressed in 4Science/DSpace#360

[jorgeltd]

Using 2023.02.01, regarding saving the metadatavalue.authority using a controlled vocabulary, I notice that when you set up a form field using repeatable true or false, the front end changes the request content, at least when editing an object.

When is repeatable the front fills the authority value on the saving request

But, when the field is not repeatable, the authority value is null

[olli-gold]

When is repeatable the front fills the authority value on the saving request

That's really interesting, thanks for catching that @jorgeltd! I have just checked that and can confirm, that it's working as you described: making the field repeatable stores the authority value and thus it's a valid workaround for the problem. But certainly the bug, that the authority value is not stored, when the field in the submission form is not repeatable, should nevertheless be fixed...

[z-stoynova]

We can also confirm that authority value for fields set with "vocabulary" and "repeatable=false", the value will be sent from frontend to backend only if the field is repeatable. Otherwise the value of the field is sent without authority when saving a change from a submission form. This was last tested in Version 2023.02.02. This was also tested in the generic DSpace Version 7.6.1. and the same problem occurs also there.

[olli-gold]

This was also tested in the generic DSpace Version 7.6.1. and the same problem occurs also there.

@z-stoynova I thought the authority values of dc.type in the database were a feature only available in DSpace-CRIS. So, does generic DSpace really store the authority values, if the field is set to repeatable? If yes, I think, we should move this issue to generic DSpace to get it addressed there.

[atarix83]

@olli-gold @z-stoynova @jorgeltd FYI this bug is going to be fixed for 2023.02.03

[z-stoynova]

This was also tested in the generic DSpace Version 7.6.1. and the same problem occurs also there.

@z-stoynova I thought the authority values of dc.type in the database were a feature only available in DSpace-CRIS. So, does generic DSpace really store the authority values, if the field is set to repeatable? If yes, I think, we should move this issue to generic DSpace to get it addressed there.

@olli-gold this problem is not specific to dc.type field .... it is a common problem for all fields which are configured with a controlled vocabullary

[olli-gold]

OK, thank you @z-stoynova - but I am still not sure, if the controlled vocabulary feature is really also available on generic DSpace or if it's rather a CRIS-exclusive feature so far. But since dc.subject is really authority controlled in generic DSpace (while dc.type is not by default) you may be right, that it's not a DSpace-CRIS-only feature.

In this case I guess it would be great to create a PR for generic DSpace as well, once it is solved here.