Allow uploading ISO metadata when UUID is different

[ahmdthr]

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]

For us, this is a valid approach to prefill metadata from a dataset series. This is also raised here: https://github.com/GeoNode/geonode-project/issues/498#issuecomment-1805568595

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]

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

[giohappy]

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

[ahmdthr]

@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]

@ahmdthr I guess you're speaking for GeoNode version < 4.1. On master, the upload is broken now (https://github.com/GeoNode/geonode/issues/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 (https://github.com/GeoNode/geonode-importer/pull/202 and https://github.com/GeoNode/geonode-importer/pull/203) and we're analyzing the work for the new UI (https://github.com/GeoNode/geonode-mapstore-client/issues/1559).

Meanwhile, we were also considering to drop the legacy code, because it has some vulnerabilities that should be fixed (https://github.com/GeoNode/geonode/issues/12046).

[giohappy]

@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]

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]

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]

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