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 add_resourcebase permission check and Contributors group concepts that have been introduced recently are currently used only by the API v2 ( to inform the client about global user permissions) and the upcoming controls for Remote Services.
There's a two-fold rationale behind this addition:
It indirectly controls the ability to make a change to the DB when the READ ONLY mode is active. In that case the control on the user permission won't return the add_resourcesbase permission. Instead of putting an explicit check on the READ_ONLY mode as is is know (see for example here) we want to check the grant through the add_resourcebase permission
It paves the road to implement read-only registered users. This is the reason of having created the Contributors group. In this moment every registered user is assigned to the group (which has the add_resourcebase permission), but we are able now to stop this automation and have registered users that are simply readers and not contributors.
To be ready for this we want to extend the adoption of the add_resourcebase check inside the templates and views where the ability to create a new resource is checked. For the moment I think the only places where the check is explicitely done is where we control the READ_ONLY configuration, so the change should be straightforward.
The text was updated successfully, but these errors were encountered:
giohappy
changed the title
Enforce the add_resourcebase permission control everywhere
Enforce add_resourcebase permission control everywhere
Jul 2, 2021
That permission is going to be reverted. The one coming for free from Django auth will be used: add_resourcebase.
This issue depends on the changes done inside this pending PR #7719.
That PR reverts the permission and adopts add_resourcebasefor contributors
@giohappy In a scenario where a user is an owner of some resources in the system then removed from the contributor's group, should they still be able to update/delete those resources?
The
add_resourcebase
permission check andContributors group
concepts that have been introduced recently are currently used only by the API v2 ( to inform the client about global user permissions) and the upcoming controls for Remote Services.There's a two-fold rationale behind this addition:
add_resourcesbase
permission. Instead of putting an explicit check on the READ_ONLY mode as is is know (see for example here) we want to check the grant through theadd_resourcebase
permissionContributors
group. In this moment every registered user is assigned to the group (which has theadd_resourcebase
permission), but we are able now to stop this automation and have registered users that are simply readers and not contributors.To be ready for this we want to extend the adoption of the
add_resourcebase
check inside the templates and views where the ability to create a new resource is checked. For the moment I think the only places where the check is explicitely done is where we control the READ_ONLY configuration, so the change should be straightforward.The text was updated successfully, but these errors were encountered: