-
-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mef export should not use local url to thumbnail #2099
Comments
this issue exists for the example metadata on the default installer, all metadata there has references to localhost:8080, which is not available if people run geonetwork on any other url or port, which for example happens on osgeo live dvd which runs geonetwork on port 8880 |
I'm not sure what could be the best approach here. How it works now: The mix of these two behaviours causes the issue. No one is bad. My first suggestion to fix the bug and the previous exports is to have an extreme approach on import, by sanitizing every url during the import. The problem are the external one, the only solution that I see here is to check if the file is in the zip, if it exists then fix the url otherwise keep it. The only issue could be when the MEF refers to external thumbnails that have an homonym in the import file. My second suggestion to fix the bug is to have a rigid approach during the export, by removing any reference to the origin in the thumbnails. This approach works with the current import behavior. The main cons are the back compatibility issues. Starting from the demo data of GN. |
I prefer the first approach (and i'm not so worried about the homonyms), so see what files are in the mef and replace any url's pointing to them with the new url Note that the same use case applies to files (resources like shape, csv, doc, pdf) being included in the mef. When metadata is exported from an intranet catalog to an extranet catalog, the links to the files should be updated to match the url of the external catalogue. |
when a metadata is exported as mef/zip and thumbnails (and resources) are embedded in the mef, then the metadata should not point to the thumbnail on the location from where this metadata is exported. in stead it should reference just the filename, and when importing the metadata should be updated to point to the location on the importing node
the node from where the metadata is exported may not be available online (it's on localhost, or it may be on an intranet)
The text was updated successfully, but these errors were encountered: