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

Fix #1559 Implement a UI component to trigger asynchronous operations on a resource #1882

Merged
merged 5 commits into from
Oct 16, 2024

Conversation

allyoucanmap
Copy link
Collaborator

@allyoucanmap allyoucanmap commented Oct 15, 2024

This PR introduces following changes:

  • introduction of a new plugin called Operation to manage async upload on a resource
  • upload of style integrated inside the dataset page using the Operation plugin
  • upload of metadata integrated inside the dataset page using the Operation plugin
  • replace of a dataset
  • refactor of document and dataset upload using the component from the Operation plugin

image

image

image

@allyoucanmap allyoucanmap self-assigned this Oct 15, 2024
@allyoucanmap allyoucanmap added this to the 5.0.0 milestone Oct 15, 2024
@allyoucanmap allyoucanmap marked this pull request as ready for review October 16, 2024 09:25
@allyoucanmap allyoucanmap requested a review from giohappy October 16, 2024 09:25
@allyoucanmap
Copy link
Collaborator Author

allyoucanmap commented Oct 16, 2024

@giohappy @mattiagiupponi this PR is working with the importer_in_core branch (GeoNode/geonode#12570). The main workflows are working but there are some harcoded configuration and minor query configuration to solve:

  • the "overwrite_existing_layer" param works only with string boolean (eg. "True"), using true throws an error on the backend
  • the SUPPORTED_DATASET_FILE_TYPES configuration is hardcoded in the client until the backend configuration has been updated (see UploadUtils for the expected configuration)
  • we need specific sources for style and metadata (resource_style_upload, resource_metadata_upload), now both are managed inside the resource_file_upload source. This helps to filter the specific list of executions

@mattiagiupponi
Copy link

mattiagiupponi commented Oct 16, 2024

we need specific sources for style and metadata (resource_style_upload, resource_metadata_upload), now both are managed inside the resource_file_upload source. This helps to filter the specific list of executions

This can be easily archived since is a matter of chaning the IF in the XML and SLD handlers

we need specific sources for style and metadata (resource_style_upload, resource_metadata_upload), now both are managed inside the resource_file_upload source. This helps to filter the specific list of executions�

This will require a refactor of the current structure of the importer configuration. The association before was 1 handler for 1 configuration, while here we want to have 1 handler with multiple configuration.
This will require:

  • change the registration from a dictionary to a list
  • change the id property of the handler and decide which will be the ID. The ID is used in the assets to set the type. i would avout to have multiple handlers for each type just to registrate the configuration.

@allyoucanmap allyoucanmap merged commit 6fba83a into master Oct 16, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement a UI component to trigger asynchronous operations on a resource
3 participants