DSpace 7 Wrong "unsafe:hdl" pemanent URIs for communities and collections

[P Z]

Hello everyone. After data migration from one DSpace 7.1 (Windows) instance to another with same version, in the another instance the permanent URI links are generated wrong (the ones informed in frontend to the user through communityPayload.handle and collection.handle variables) . Instead a proper, real URL such as https://repo.com/handle/123456879/2 (say for instance), the resulting link for these migrated communities and collections is unsafe:hdl:123456789/2 . Migrated article links are right. And with communities/collections/articles newly created after migration, their links are also right. 

For the wrong "unsafe:hdl" links, how could I fix it? (preferably without wiping/reloading DB)

Thanks in advance.

(

Command line used for export:

dspace packager -d -a -t AIP -e ad...@xxx.xxx -i 123456789/0 output.zip

And for import:

dspace packager -r -a -f -t AIP -e  ad...@xxx.xxx  -i 123456789/0 -o skipIfParentMissing=true c:\output.zip

)

[Tim Donohue]

Hi,

If I recall correctly, I believe Angular automatically adds "unsafe:" before any URL which is not a valid URL.  So, that'd imply to me that these Community/Collection URLs are possibly being saved as "hdl:123456789/2" and the Angular UI tries to display them as links, which causes Angular to display them as "unsafe:hdl:1234356789/2".

So, it sounds to me like somehow the import process is having trouble transforming "hdl:123456789/2" (which is how it's stored in an AIP) into "https://repo.com/handle/123456789/2".   It might be something as simple as having a misconfigured "handle.canonical.prefix" or "handle.prefix" setting in your local.cfg (or dspace.cfg).  Or, maybe there's some other error occurring during the import?

There are a few options I can think of.  

• You might try the import again (a re-import should simply replace the existing objects .. overwriting them.)  If you do this, you may want to pay close attention to your dspace.log files to see if any errors appear there.  Also make sure "handle.canonical.prefix" and "handle.prefix" are set correctly first.  This is the easiest approach
• Or, at the database level, you could modify the "dc.identifier.uri" metadata field to have the correct value. You'd have to first determine the "metadata_field_id" of that field from metadatafieldregistry (e.g. select * from metadatafieldregistry where element='identifier' and qualifier='uri';)   Then, you'd need to update the "text_value" values of that field in the "metadatavalue" table.  I don't have an exact query for that one, you should see "text_value" values that start with "hdl:" when you really want this field to be a full URL.
  

Others on this list might think of additional options, but those are the two fixes that I immediately think of.  Technically, the import process should be transforming these values into full URLs, but it's unclear to me why that isn't working correctly in this case.  I'm hoping that if you simply correct the "handle.*" configs (if they are incorrect) and try again, it might work.

Good luck and let us know on this list if you need more help.

Tim

---

From: dspac...@googlegroups.com <dspac...@googlegroups.com> on behalf of P Z <pedrozul...@gmail.com>
Sent: Friday, August 5, 2022 11:02 AM
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] DSpace 7 Wrong "unsafe:hdl" pemanent URIs for communities and collections

 

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/46e30b83-95aa-4b23-9f72-c55e0980f509n%40googlegroups.com.