[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.
[dspace-tech] Re: Dspace 7.6.1 Batch import via SAF fails due to "invalid" imports directory
Hi Matthias, It's not the SAF files but my guess it's happening because of a corrupted zip file so check it using the 7zip package. Have it install in the server and check the zip file for its integrity. *** You can force the extraction of the zip file using 7zip even with the issue it has ( Watch for any errors during the extraction phase ) and then import the SAF files from a directory. Good luck, Mo. On Friday, February 2, 2024 at 4:04:13 PM UTC+3 Matthias Letsch wrote: > Hi there, > > I am trying to import prepared SAF files via batch import. With another > subset in other collections, this worked wonderfully just yesterday. So it > can't be the SAF files, they follow exactly the same pattern (zip with > folders containing xyz.pdf, dublin_core.xml and contents referring to pdf > file. > > Today, however, I get an error message (This is now a dedicated test > import into a newly created collection TEST): > > ###:~/dspace-backend/bin$ ./dspace import -a -e ###@###.de -s ~/ojs-import > -z 10.zip -c 12345678 > 9/5103 -m ~/ojs-import/mapfiles/test10; > The script has started > Destination collections: > Owning Collection: TEST > '/home/dspace/dspace-backend/imports' as defined by the key > 'org.dspace.app.batchitemimport.work.dir' in dspace.cfg is not a valid > directory > Started: 1706876840214 > Ended: 1706876846622 > Elapsed time: 6 secs (6408 msecs) > java.lang.Exception: Error committing changes to database: Error, cannot > open source directory > /home/dspace/dspace-backend/imports/importSAF/43013a47-6076-432a-959d-9805240a43ae/10.zip, > > aborting most recent changes > at > org.dspace.app.itemimport.ItemImport.internalRun(ItemImport.java:233) > at org.dspace.scripts.DSpaceRunnable.run(DSpaceRunnable.java:150) > at > org.dspace.app.launcher.ScriptLauncher.executeScript(ScriptLauncher.java:154) > at > org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:132) > at > org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:99) > Caused by: java.lang.Exception: Error, cannot open source directory > /home/dspace/dspace-backend/imports/importSAF/43013a47-6076-432a-959d-9805240a43ae/10.zip > at > org.dspace.app.itemimport.ItemImportServiceImpl.addItems(ItemImportServiceImpl.java:278) > at > org.dspace.app.itemimport.ItemImportCLI.process(ItemImportCLI.java:92) > at > org.dspace.app.itemimport.ItemImport.internalRun(ItemImport.java:226) > ... 4 more > > As I understand it, there is some problem with the folder > (dspace-dir)/imports, which exists exactly as it is defined in dspace.cfg. > > If I create a new, different folder in the backend and then change this in > dspace.cfg (plus restart tomcat), the result unfortunately looks exactly > the same. > > Does anyone know how to fix this problem? > > Thank you and kind regards > Matthias > -- 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/cea4f41e-a75e-4abb-bb0f-0c918c680712n%40googlegroups.com.
[dspace-tech] Re: Thumbnail generation for items in DSpace 7.5 is not working
Thank you, Mercedes. I found the issue. I am migrating the digital library from version 6.3 to 7.5. The migration changed the access policies, and when I logged in, the thumbnails became available. So, I just need to adjust the access policies to make them available for anonymous users, and everything will be fine. Em sexta-feira, 2 de fevereiro de 2024 às 13:51:47 UTC-3, Mercedes escreveu: > Hello, I had to do it manually until I enabled the solr text indexing, I > can't say why but it sarted to create thumbails from images and pdfs. > Note that Dspace indexes by default the uploaded files at 3 AM, is > possible to change it. So when you upload a file, the next day you will see > the thumbnail. I hope this helps! > > El viernes, 2 de febrero de 2024 a la(s) 11:56:41 a.m. UTC-3, Lucas > Silveira escribió: > >> Dear Collegues, >> I am working with DSpace 7.5 and facing difficulties in generating >> thumbnails for approximately 50,000 items. I have tried generating >> thumbnails using the "./dspace filter-media" command, but without success. >> Subsequently, I attempted to generate thumbnails for each collection using >> the "./dspace filter-media -i handle" command and executed the "./dspace >> index-discovery -b" command, but still, I did not succeed. I have not made >> any changes to the variables in the dspace.cfg file. Does anyone have any >> suggestions or know where I might be going wrong? I appreciate your help in >> advance. >> > -- 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/21ca26ef-ca46-4bdb-a841-953a9fe81e5an%40googlegroups.com.
[dspace-tech] Re: Thumbnail generation for items in DSpace 7.5 is not working
Hello, I had to do it manually until I enabled the solr text indexing, I can't say why but it sarted to create thumbails from images and pdfs. Note that Dspace indexes by default the uploaded files at 3 AM, is possible to change it. So when you upload a file, the next day you will see the thumbnail. I hope this helps! El viernes, 2 de febrero de 2024 a la(s) 11:56:41 a.m. UTC-3, Lucas Silveira escribió: > Dear Collegues, > I am working with DSpace 7.5 and facing difficulties in generating > thumbnails for approximately 50,000 items. I have tried generating > thumbnails using the "./dspace filter-media" command, but without success. > Subsequently, I attempted to generate thumbnails for each collection using > the "./dspace filter-media -i handle" command and executed the "./dspace > index-discovery -b" command, but still, I did not succeed. I have not made > any changes to the variables in the dspace.cfg file. Does anyone have any > suggestions or know where I might be going wrong? I appreciate your help in > advance. > -- 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/45eecb13-f42b-4be1-8875-a329e1712991n%40googlegroups.com.
[dspace-tech] DSpace 7.6.1 How to suppress automatic DOI generation and registration for imported items?
Hi there, I have activated automatic DOI generation and registration for new items on Datacite. Above all, items that are newly submitted manually via the submission form should receive a DOI. I am also currently testing a mass import of an old external repository via batch import (SAF). This involves a quantity of around 8k items. For a subset of about 150 items imported yesterday as a test, all items have now been automatically provided with new DOIs and these have been sent to Datacite fabrica test. However, these items (old journal articles) should not receive a DOI at all, as some of them already have one. Furthermore, registering all these items in the productive system would be incredibly expensive. It is therefore absolutely necessary to suspend the DOI registration for these items. I have also noticed that a new DOI is always generated automatically when importing e.g. articles from external sources such as CrossRef, which a user can also initiate. However, most imported articles already have a DOI. Is there a way to prevent DOI registration for imports without deactivating it completely? Or can it be set somewhere so that only items received via the input screen actually receive a new DOI? Thank you and kind regards, Matthias -- 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/d481a19c-bb32-4781-af0a-218e6015ba67n%40googlegroups.com.
[dspace-tech] REQUEST FOR ADVICE
I am working on DSpace 7.5 with Software as a Service (SAS) , thus, I do not have access to the backend. I have been trying to import 4.1MB metadata for days now but it keep on failing. Please, I need help on best approach to the import. Benneth -- 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/7b076f9a-a9d6-41bc-bf28-61214b553fc2n%40googlegroups.com.
[dspace-tech] Thumbnail generation for items in DSpace 7.5 is not working
Dear Collegues, I am working with DSpace 7.5 and facing difficulties in generating thumbnails for approximately 50,000 items. I have tried generating thumbnails using the "./dspace filter-media" command, but without success. Subsequently, I attempted to generate thumbnails for each collection using the "./dspace filter-media -i handle" command and executed the "./dspace index-discovery -b" command, but still, I did not succeed. I have not made any changes to the variables in the dspace.cfg file. Does anyone have any suggestions or know where I might be going wrong? I appreciate your help in advance. -- 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/f8fd378f-9898-440c-82a1-832cb8cc76e6n%40googlegroups.com.
[dspace-tech] Dspace 7.6.1 Batch import via SAF fails due to "invalid" imports directory
Hi there, I am trying to import prepared SAF files via batch import. With another subset in other collections, this worked wonderfully just yesterday. So it can't be the SAF files, they follow exactly the same pattern (zip with folders containing xyz.pdf, dublin_core.xml and contents referring to pdf file. Today, however, I get an error message (This is now a dedicated test import into a newly created collection TEST): ###:~/dspace-backend/bin$ ./dspace import -a -e ###@###.de -s ~/ojs-import -z 10.zip -c 12345678 9/5103 -m ~/ojs-import/mapfiles/test10; The script has started Destination collections: Owning Collection: TEST '/home/dspace/dspace-backend/imports' as defined by the key 'org.dspace.app.batchitemimport.work.dir' in dspace.cfg is not a valid directory Started: 1706876840214 Ended: 1706876846622 Elapsed time: 6 secs (6408 msecs) java.lang.Exception: Error committing changes to database: Error, cannot open source directory /home/dspace/dspace-backend/imports/importSAF/43013a47-6076-432a-959d-9805240a43ae/10.zip, aborting most recent changes at org.dspace.app.itemimport.ItemImport.internalRun(ItemImport.java:233) at org.dspace.scripts.DSpaceRunnable.run(DSpaceRunnable.java:150) at org.dspace.app.launcher.ScriptLauncher.executeScript(ScriptLauncher.java:154) at org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:132) at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:99) Caused by: java.lang.Exception: Error, cannot open source directory /home/dspace/dspace-backend/imports/importSAF/43013a47-6076-432a-959d-9805240a43ae/10.zip at org.dspace.app.itemimport.ItemImportServiceImpl.addItems(ItemImportServiceImpl.java:278) at org.dspace.app.itemimport.ItemImportCLI.process(ItemImportCLI.java:92) at org.dspace.app.itemimport.ItemImport.internalRun(ItemImport.java:226) ... 4 more As I understand it, there is some problem with the folder (dspace-dir)/imports, which exists exactly as it is defined in dspace.cfg. If I create a new, different folder in the backend and then change this in dspace.cfg (plus restart tomcat), the result unfortunately looks exactly the same. Does anyone know how to fix this problem? Thank you and kind regards Matthias -- 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/07b05c25-f1ce-4dd1-901b-74ff7e9f983bn%40googlegroups.com.
