Skip to content
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

Open
ahmdthr opened this issue Jan 30, 2024 · 9 comments · May be fixed by #11904
Open

Allow uploading ISO metadata when UUID is different #11903

ahmdthr opened this issue Jan 30, 2024 · 9 comments · May be fixed by #11904

Comments

@ahmdthr
Copy link
Contributor

ahmdthr commented Jan 30, 2024

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.

@gannebamm
Copy link
Contributor

gannebamm commented Jan 30, 2024

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.

@giohappy
Copy link
Contributor

@ahmdthr what is the expected behaviour in case this flag is turned on?
It will preserve the UUID provided in the file, which will differ from the one assigned to the dataset in GeoNode.

image

@giohappy
Copy link
Contributor

giohappy commented Feb 8, 2024

@ahmdthr news on this PR? Could you clarify what I was asking in my previous comment?

@ahmdthr
Copy link
Contributor Author

ahmdthr commented Feb 15, 2024

@ahmdthr news on this PR? Could you clarify what I was asking in my previous comment?

@giohappy Even when the UUID is different, it only updates the resource but not the UUID. The UUID of a resource and within the ISO metadata stays the same. Is that what you were expecting?

@giohappy
Copy link
Contributor

giohappy commented Mar 14, 2024

@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).

@giohappy
Copy link
Contributor

giohappy commented Mar 21, 2024

@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.
In case the UUID of the uploaded file differs from the actual UUIS of the resource you will end up downloading a metadata file where the UUID doesn't match that from the resource since the XML file won't be generated but the original (uploaded) file will be served instead. This would propagate a misalignment between the metadata file and the (real) resource UUID in GeoNode.

How do you deal with this @gannebamm?

@gannebamm
Copy link
Contributor

Hi @giohappy
The business/use case of this functionality is to allow our users to 're-use' metadata they already have created for datasets in a series and edit some values after applying the 'template'. Those users are not able to easily use the REST API to apply those XML values to the new dataset.

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.

@ridoo
Copy link
Contributor

ridoo commented Mar 22, 2024

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

@giohappy
Copy link
Contributor

giohappy commented Mar 22, 2024

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants