-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow uploading ISO metadata when UUID is different #11903
Comments
For us, this is a valid approach to prefill metadata from a dataset series. This is also raised here: GeoNode/geonode-project#498 (comment) With the PR the behaviour of uploading a XML file is the same as with a SLD file. An SLD file will also overwrite the current style information and display a warning in the upload dialogue. |
@ahmdthr what is the expected behaviour in case this flag is turned on? |
@ahmdthr news on this PR? Could you clarify what I was asking in my previous comment? |
@ahmdthr I guess you're speaking for GeoNode version < 4.1. On master, the upload is broken now (#11467). We're planning to replace the legacy forms and views with a new UI based on the asynchronous upload APIs, the same that are used for the upload. The backend is ready (GeoNode/geonode-importer#202 and GeoNode/geonode-importer#203) and we're analyzing the work for the new UI (GeoNode/geonode-mapstore-client#1559). Meanwhile, we were also considering to drop the legacy code, because it has some vulnerabilities that should be fixed (#12046). |
@ahmdthr we've just merged a PR also (backported to 4.2.x) where metadata and SLD uploads are working again. The question in my comment was, if you preserve the uploaded metadata file it will be what is returned when you download the metadata as ISO file from the resource menu. How do you deal with this @gannebamm? |
Hi @giohappy Another approach would be to allow the 'copying' of the metadata of a dataset. That approach was declined due to limited resources and the current complexity with mapstore frontend development. If the community does not see our business/ use case as broadly needed I am fine with the feature staying in our fork. |
You could also think of replacing the UUID within the XML in case the UUID does not match? This would work, of course, only, if there is no expectation to update the UUID of an existing dataset. Maybe, this could be checked on client side and show a warning instead? @gannebamm not sure, if this would be beyond scope TBH |
I understand the business case, and it could be useful for many, but the question remains: how do you deal with preserved metadata? Of course you don't have this problem if you don't preserver the XML file. EDIT: I just read your comment here, and it confirms you're not using the preserve metadata option :) |
Is your feature request related to a problem? Please describe.
When an XML metadata is uploaded via the form or REST API, if the UUID differs from the resource, the system rejects the upload altogether.
Describe the solution you'd like
If the UUID is different, the system should disregards the difference and update the resource according to the uploaded XML metadata.
Describe alternatives you've considered
A work around is to edit the metadata file to update the UUID according to the resource's UUID, but it becomes an inconvenience pretty soon.
Additional context
No.
The text was updated successfully, but these errors were encountered: