enum for data ingestion.

[lgalke]

Uploading fails for collections due to No enum match for: COLLECTION:

400 - Bad Request {"message":"Validation errors","errors":[{"code":"INVALID_REQUEST_PARAMETER","errors":[{"code":"ENUM_MISMATCH","params":["COLLECTION"],"message":"No enum match for: COLLECTION","path":[],"description":"The type of the resource."}],"in":"formData","message":"Invalid parameter (resourceType): Value failed JSON Schema validation","name":"resourceType","path":["paths","/saveScan","post","parameters","5"]}]}

Checking your code, I assume that the new corresponding enum will be embodimentType such that we have current MONOGRAPH, COLLECTION mapped to PRINT and else DIGITAL?

The Monograph upload still works somewhat surprisingly.

[kleinann]

I suppose the question was rather directed at Anne. Anyway, the idea for the embodimentType was that it can be specified, but doesn't have to be specified for all resource types.

[anlausch]

No, it's not the embodiment type. It's the Crossref resource types this message is about (enum: resourceType). The COLLECTION type just does not exist here, therefore it is not going to be available anymore. A suitable type is for example BOOK_CHAPTER. But there are going to be more changes which were discussed on Thursday.

[lgalke]

Ah I was not aware that these changes would affect file upload already now. Did not intend to bother you when you are in the middle of changes. For now I will then replace COLLECTION with BOOK_CHAPTER in case of the file upload?

I was checking the files below, which still hold the old possible enum values.

• line 514 in swagger.yaml
• line 21-24 in enum.json

[anlausch]

No problem. The master branch just didn't have the changes until today morning as this one is always the productive version and therefore will be merged with a delay. Your solution looks fine for now.

[lgalke]

Okay, thanks 👍