search

4Science / dspace-angular

Angular UI for DSpace and DSpace-CRIS. In the dspace-cris-7 branch you can find the extension to support DSpace-CRIS
BSD 3-Clause "New" or "Revised" License
14 stars 28 forks source link

Authority for document types is not stored in the authority field #64

Open olli-gold opened 9 months ago

olli-gold commented 9 months ago

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 https://github.com/4Science/DSpace/issues/360

jorgeltd commented 9 months ago

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 coar_repeatable

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

olli-gold commented 9 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

z-stoynova commented 6 months ago

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 commented 6 months ago

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.