Data Deposit API: Contributor Type can be changed

[eaquigley]

Using the Data Deposit API, a metadata field with a controlled vocabulary can be changed without an error being thrown. For example, the contributor type field has funder as an option. In the API you can change it from funder to smurffunder and it will save the dataset with that.

[pdurbin]

The good news is that if you try to use "SmurfFunder" rather than "Funder" with the native API you get an error:

$ curl -s -X POST -H Content-type:application/json -d @scripts/search/data/dataset01-create-new.json 'http://localhost:8080/api/dvs/12/datasets/?key=5fa1ae77-40cb-4c3f-a9d4-61a91e48af7e' | jq .
{
"message": "Error parsing initialVersion: Value 'SmurfFunder' does not exist in type 'contributorType'",
"status": "ERROR"
}

Ideally, the API would be able to report back the valid values so native API users doesn't have to look them up in the docs. I couldn't quickly figure out how to make the native API do this (we could open a new ticket for this). Here's the JSON I used to tickle the validation message above:

          {
            "value": [
              {
                "contributorName": {
                  "value": "MyContributor",
                  "typeClass": "primitive",
                  "multiple": false,
                  "typeName": "contributorName"
                },
                "contributorType": {
                  "value": "SmurfFunder",
                  "typeClass": "primitive",
                  "multiple": false,
                  "typeName": "contributorType"
                }
              }
            ],
            "typeClass": "compound",
            "multiple": true,
            "typeName": "contributor"
          }

The SWORD API (Data Deposit API) uses a different code path than the native API. It uses the importXML() method developed in #572. Apparently, different validation is in place there. To reproduce problem this bug is about, you can use this line of XML with SWORD:

<dcterms:contributor type="SmurfFunder">No validation/enforcement of controlled vocabulary for contributorType</dcterms:contributor>

See also #899 (comment) where this bug was first described.

[scolapasta]

@pdurbin I think this is the same type of issue you had with the duplicate subjects (at least I'm assuming your code was written in the same way, creating a new CVV, instead of looking it up. Can you check if this is the issue?

[pdurbin]

@scolapasta the bug would be in the importXML method developed by @landreev in #572 but sure, I can take a quick look. You want validation to happen in the importXML method and in the "native" API (must already be in there somewhere)? Not centralized at all?

[pdurbin]

@scolapasta I took at quick look the importXML method @landreev wrote for #572 but it's complicated and since he's saying "Do note that we are junking this implementation of foreign metadata import" at #572 (comment) (in favor or the code @ekraffmiller will be working on for the "Batch API" presumably) I'm going to give this ticket to @ekraffmiller to think about as she works on an alternative to the importXML method. The API spreadsheet says the Batch API is for beta 10 so I'll change the milestone as well.

[ekraffmiller]

This validation check is done in the JsonParser, so bug will be fixed when we switch dcterms import to use JsonParser.

[scolapasta]

#rtreacy - is this fixed now that that import goes through the Json?

[rtreacy]

The new json based importXML has been incorporated into ContainerManageImpl and CollectionDepositManagerImpl.

[pdurbin]

The new json based importXML has been incorporated into ContainerManageImpl and CollectionDepositManagerImpl.

That commit was 2467468 and after it I can't edit datasets via SWORD, which I reported in #1554

Locally, I backed up to the commit before (811fd5b) and I can edit datasets with SWORD.