You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
andAdvancedSecurityWorkflowManager.is_allowed_to_approve
. We should probably basesecurity.utils.can_approve(user, resource)
andsecurity.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 staticpublish_resourcebase
Permissions, as it is now. This permissions, as well as the approval permission, should be calculated dynamically. Having a staticpublish_resourcebase
doesn't make sense, and it should be removed in the future.The text was updated successfully, but these errors were encountered: