Hi Chris, While the "dspace.entity.type" metadata field does exist in the database by default, it is not used by default in the submission forms, etc. So, you shouldn't need to modify any configurations to disable that field from being used in the creation/deposit process.
However, it seems you are correct that it *is* possible for an Administrator to add a "dspace.entity.type" metadata field to an existing Item if they edit the Item, search for that field and add it manually to the Item. This is unlikely to occur, but it is a possible mistake someone could make (and it sounds like that happened for you). The odd thing though is that adding an invalid "dspace.entity.type" should NOT block your ability to delete or edit the Item. That was a bug in 7.1, but we fixed it in 7.2 in this PR: https://github.com/DSpace/dspace-angular/pull/1503 So, that's confusing to me why you still experienced this bug. If you have the time to document how this occurred, or (if you have a test site which you can play with) you are willing to try and reproduce the issue, it'd be very useful to use if you could create a bug ticket in https://github.com/DSpace/dspace-angular/issues It sounds like you've hit some behavior that is entirely unexpected, and either we should consider blocking people from manually adding the "dspace.entity.type" field, or find a way to ensure that doing so doesn't cause unexpected errors. But, in order to track that down, we'd need more information on how to potentially reproduce this bug in an issue ticket. Thanks, Tim On Thursday, May 12, 2022 at 10:01:07 AM UTC-5 Chris Clawson wrote: > I understand that 'Relationships' and configurable entities are now part > of DS Angular 7.2. It seems to be controlled by a new (?) metadata term, > 'dspace.entity.type' , which enabled the ability to edit values under the > Edit> Relationships tab. This term now seems enabled by default when a new > item is created. > > We are not planning to use this feature in the near future and one of our > editors mistakenly just entered invalid data into this term while editing > an item. This changed the item into an undefined entity. The caused the > item to be uneditable and we could not delete it. It also may have > corrupted metadata exports at the collection level. > > Fortunately, I was able to correctly export Community metadata as a CSV > spreadsheet. A column for the term 'dspace.entity.type' was defined and I > was able to find and delete the cell with the bad data. Importing the > correcting, single row csv fixed my problem for this item and I was then > able to edit the item and normally export collection metadata. > > Question: Can/should I disable the default addition of this term when > creating a new item? Can someone provide a config file and method to do > this? We could always enable it later, right? > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/e7d28208-71bd-4b80-a024-4777b866c0den%40googlegroups.com.
