[dspace-tech] Re: Relationships problem and question
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 dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/e7d28208-71bd-4b80-a024-4777b866c0den%40googlegroups.com.
[dspace-tech] Re: Relationships problem and question
I was unable to post the bug to GitHub, because of my account status. Below is my report. Might you or somebody please Submit it? ** *Invalid data in dspace.entity.type makes item uneditable* DSpace Angular 7.2 Ubuntu 20.04 web server *Accidental or improper entries in an item's dspace.entity.type metadata causes the item to hang DSpace when attempting to view or edit. The item may only then be fixed by importing a data corrected CSV spreadsheet.* *Repeatable prodedure:* Select a normal and good item and edit the contents of dspace.entity.type with the following: Couture Bros., Turners Falls, Montague, Franklin County (This was the data erroneously added in the original problem) Once saved, the item will display in Collection summaries (showing the bad data as an entity) but will hang DSpace and prevent viewing, editing or deletion. *Discussion:* This was caused in error by an associate with admin privileges who mistook the 'Relationships' tab for a place to enter keywords. I was also able to find this tab active (with a drop down menu), but have since found it only saying “Add 'dspace.entity.type' metadata to enable relationships for this item “. The main Metadata Edit tab shows 'dspace.entity.type' as being defined, but with no data in the cell. I still do not know how to activate this 'Relationships' tab and repeat the exact scenario I believe led to the problem. (corrupted exports?) I also originally had Collection level metadata exports either failing or providing the wrong collections. I was able to fix the original problem by successfully exporting at the Community level, deleting the contents of the bad cell and then importing back that row to DSpace. I am sorry I can't repeat the other points raised in this discussion, but hopefully focusing on the repeatable portion will prevent the other stuff in the future. On Thursday, May 12, 2022 at 11:25:38 AM UTC-4 Tim Donohue wrote: > 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
[dspace-tech] Re: Relationships problem and question
Buenas tardes. En mi caso, el problema se presenta cuando voy a crear una nueva colección y debo seleccionar el tipo de entidad (collection.form.entityType), este metadato no muestra ningún valor, no se despliega. Podrían orientarme en la solución. ¿Dóndedebo definir o habilitar los tipos de entidad para que puedan visualizarse? Saludos. Emilia.- El jueves, 12 de mayo de 2022 a las 12:25:38 UTC-3, Tim Donohue escribió: > 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 dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/ae322fea-d9f1-4389-aa16-5feda0d5588dn%40googlegroups.com.
