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

Refactor how resource permissions are set inside the mapstore client context #7444

Closed
marthamareal opened this issue May 2, 2021 · 0 comments
Assignees
Labels
major A high priority issue which might affect a lot of people or large parts of the codebase
Milestone

Comments

@marthamareal
Copy link
Contributor

Expected Behavior

1. __GEONODE_CONFIG__.permissionsList should be renamed to __GEONODE_CONFIG__.perms(These should be GeoNode resource permissions not guardian perms.)
2. on view map : __GEONODE_CONFIG__.perms should have all permissions a user has on a viewed map.
3. on view layer: __GEONODE_CONFIG__.perms should have all permissions a user has on a viewed layer.
4. on view geostory: __GEONODE_CONFIG__.perms should have all permissions a user has on a viewed geostory.

Actual Behavior

Currently GeoNode returns the permissions in multiple ways:

  • on view layer: an empty __GEONODE_CONFIG__.permissionsList is returned. The client is using resourceConfig.map.info instead
  • on view map : same as above
  • geostory viewer: apparently it returns all the existing Django permissions strings inside __GEONODE_CONFIG__.permissionsList (and it also returns add_resourcebase see Define add_resourcebase permission for users geosolutions-it/nexus-geonode#84)

Steps to Reproduce the Problem

  1. Visit https://master.demo.geonode.org/maps/1726/view#/ and check the GEONODE_CONFIG.permissionsList in the console.

Specifications

  • GeoNode version: master
  • Installation method (manual, GeoNode Docker, SPCGeoNode Docker):
  • Platform:
  • Additional details:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major A high priority issue which might affect a lot of people or large parts of the codebase
Projects
None yet
Development

No branches or pull requests

2 participants