Bug in /api/admin/datasetfield/load - possible to overwrite a field with a field with the same name IN A NEW BLOCK

[landreev]

Our datasetfieldtype setup relies on the fields being unique across all the metadatablocks installed. That's how the API knows if it's a new field, or a field that needs to be updated when you reimport a block from a .tsv file, etc. There appears to be a problem with that arrangement - it is possible to add a NEW block with a field that has the name of an existing field in another block; and it will silently overwrite an existing field, and reattach it to the new block. Thus changing the nature of any existing field values in the database.

We probably want the api to reject to load a new block with a “sorry, you already have an installed block xyz that has the field type with the name abc”.

Also, we could add something to our docs on how to create new blocks. To encourage people to use less generic names for the fields in their custom blocks; along the lines of myBlockSpecificRepository instead of simply Repository.

Edit: there was a suggestion to provide a flag that would force the API to move an existing field from an existing block and into a new one (i.e., the current behavior); in case an installation admin actually has reasons to want to do this.

[pdurbin]

Nice write up. To give a concrete example, I was playing around with two metadata blocks that both had codeRepository as a field. For the dataset I created, the duplicate field moved from the original block to the block where the field was overwritten. That is, in the screenshot below, the "Code Repository" field moved from the "Computational Workflow" block to the "Software/CodeMeta" block:

(We have a plan to rename these fields so they don't conflict.)

I agree, rejecting the loading of the new block due to duplicates seems like a great first step.