This proposes that we track permissions for models... that are used for tracking permissions.
Apps should already be able to do this themselves like
from ansible_base.rbac import permission_registry
from ansible_base.rbac.models import RoleDefinition
permission_registry.register(RoleDefinition, parent_field_name=None)
But this is unsatisfactory for a number of reasons. Firstly, the model RoleDefinition is owned by DAB itself, so the permissions are enumerated in the Meta class for the model, which the app has no control over. And clearly, the "view" permission makes no sense for that model, so only DAB can remove it for it to behave as expected.
This is expected to be somewhat opinionated, just as the API itself is. If you don't like it, build your own API.
Here is a spitball of some initial code changes for this:
In that branch, I've included what I believe are the maximum permissions that we might enumerate. So while this removes some permissions, I could see us removing more.
RoleDefinition
add
change
delete
Assignment models
add
delete
view
My thought here is that we would only employ these as system-level permissions, if they are employed at all. An assignment, for instance, can be created if the user has the related permission to the content_object for that assignment. So generally, we shouldn't need to track an "add" permission. The only reason we would have this is to do a re-construct superuser permissions, so you could be a permission superuser, so you could give anyone any permission. I should say, I don't like that, because having the assignment "add" permission effectively gives you all other permissions (because you could assign yourself anything). So I find this somewhat incoherent. My minimal proposal would be:
RoleDefinition
add
change
delete
Assignment models
view
The idea is that we OR system-level permissions with other permissions. So if you have view permission to role assignments, you can view all role assignments regardless of your permissions to the content object of the assignment.
It is fairly coherent to allow normal users to create, change, and delete role definitions.
This proposes that we track permissions for models... that are used for tracking permissions.
Apps should already be able to do this themselves like
But this is unsatisfactory for a number of reasons. Firstly, the model
RoleDefinitionis owned by DAB itself, so the permissions are enumerated in theMetaclass for the model, which the app has no control over. And clearly, the "view" permission makes no sense for that model, so only DAB can remove it for it to behave as expected.This is expected to be somewhat opinionated, just as the API itself is. If you don't like it, build your own API.
Here is a spitball of some initial code changes for this:
https://github.com/ansible/django-ansible-base/compare/devel...AlanCoding:so_meta?expand=1
This has https://github.com/ansible/django-ansible-base/pull/475 as a dependency.
In that branch, I've included what I believe are the maximum permissions that we might enumerate. So while this removes some permissions, I could see us removing more.
My thought here is that we would only employ these as system-level permissions, if they are employed at all. An assignment, for instance, can be created if the user has the related permission to the
content_objectfor that assignment. So generally, we shouldn't need to track an "add" permission. The only reason we would have this is to do a re-construct superuser permissions, so you could be a permission superuser, so you could give anyone any permission. I should say, I don't like that, because having the assignment "add" permission effectively gives you all other permissions (because you could assign yourself anything). So I find this somewhat incoherent. My minimal proposal would be:The idea is that we OR system-level permissions with other permissions. So if you have view permission to role assignments, you can view all role assignments regardless of your permissions to the content object of the assignment.
It is fairly coherent to allow normal users to create, change, and delete role definitions.