Edit Metadata API endpoint - not allowing empty values

[g-saracca]

What steps does it take to reproduce the issue?
Try to update a dataset metadata sending a payload with empty values like:

[
...rest of required fields,
{
    "value": "",
    "typeClass": "primitive",
    "multiple": false,
    "typeName": "subtitle"
}]

And you will receive an error like:

{
    "status": "ERROR",
    "message": "Error parsing dataset update: Empty value for field: Subtitle"
}

• What happens?
  API endpoint is returning an error, but on updates it should allow empty values on not required fields as users may want to remove a value from a field and leave it empty.

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

• What did you expect to happen?
  Not to receive an error and update the metadata correctly.

Which version of Dataverse are you using?
unstable

Any related open or closed issues to this bug report?
After this gets fixed we should continue with frontend issue IQSS/dataverse-frontend#598.

Screenshots:

[pdurbin]

I poked around with this a bit.

It's possible to delete a subtitle, for example, using this API: https://guides.dataverse.org/en/6.5/api/native-api.html#delete-dataset-metadata

As the docs, say, it has to be an exact match. This is the JSON I used:

{
  "fields": [
    {
      "typeName": "subtitle",
      "value": "mySubtitle"
    }
  ]
}

This and related APIs were added in this PR:

• 3599 api for simple dataset edits #4736

[g-saracca]

Hi @pdurbin , thanks for those recommendations, but we need to stick to the edit metadata endpoint we were using, as it works with a similar DTO as the create dataset endpoint and we are also reusing the form component in the SPA for both creating and editing a dataset.

[qqmyers]

How will this work with multiple values? Do you have to send all of the existing ones to know which is now blank?

[GPortas]

How will this work with multiple values? Do you have to send all of the existing ones to know which is now blank?

Currently, it's the preferred way I see to do it. Do you see any downside apart from having to know and send the values you want to keep?

[qqmyers]

I guess if one more is added since you last looked, the delete becomes ambiguous. As for alternatives, as Phil said we do have the delete api call, but if it helps to allow this in edit, I could imagine a delete flag, e.g. sending the original value that you're removing with a delete=true versus sending an empty value. (I don't recall - did we ever decide on how to be sure you have the latest info when making api calls, which is what keeping the datasetversion.version integer does for the current UI (causing OpportunisticLockException if your version is behind the one on the db due to someone else's change.)).

[GPortas]

@qqmyers I've been discussing with @g-saracca, and we believe the best approach is to send the API the datasetversion.version integer along with the updated metadata fields. The API would then verify that no consecutive version numbers have been registered, returning an error if they have.

This way, the payload would include only empty values for deletions, eliminating concerns about unintentionally deleting unknown data, as the user must have the latest version for the update to proceed. I have resized the issue to incorporate this check within its scope.

[qqmyers]

Is this something we want across the API, e.g. version as an optional (for backward compatibility) param on anything that updates the datasetversion? Not to slow this issue down, but maybe put the check in the Abstract api bean so it can be reused in other calls?

[GPortas]

Yes, definitely. At least design the solution to be reusable from other endpoints within the scope of this issue.