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

Implment can_feature, can_publish and can_approve methods #8848

Closed
giohappy opened this issue Feb 22, 2022 · 0 comments
Closed

Implment can_feature, can_publish and can_approve methods #8848

giohappy opened this issue Feb 22, 2022 · 0 comments
Assignees
Labels
Milestone

Comments

@giohappy
Copy link
Contributor

giohappy commented Feb 22, 2022

The logic to enable/disable these actions is currently spread all over the GeoNode codebase, making its maintenance and reuse hard or impossible.

The following methods will be implemented under the security.utils.py module:

  • can_feature(user, resource)
  • can_approve(user, resource)
  • can_publish(user, resource)

For each of them a proxy method will also be implemented inside the Profile model e.g. Profile.can_approve(resource) -> security.utils.can_approve(user, resource).

can_approve/can_publish

These methods will implement this logic and they will replace all the blocks of code, similar to this one, where the logic is repeated.

can_feature

For the moment we will restrict the permission to set a resource as featured to superadmins only.
Same as for can_approve and can_publish, this control will replace the inlined controls.

EDIT: we already have AdvancedSecurityWorkflowManager.is_allowed_to_publish and AdvancedSecurityWorkflowManager.is_allowed_to_approve. We should probably base security.utils.can_approve(user, resource) and security.utils.can_publish(user, resource) on these, and they should be adapted as the following:

  • is_allowed_to_publish: it shouldn't rely on a static publish_resourcebase Permissions, as it is now. This permissions, as well as the approval permission, should be calculated dynamically. Having a static publish_resourcebase doesn't make sense, and it should be removed in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants