Content
View differences
Updated by Klaus Zanders almost 3 years ago
To allow groups and users to be added to work packages, we can extend the existing `members` system to not only allow linking to a project, but also to an additional polymorphic relation called `entity`:
* We already know that we will need to extend the system in the future, because other models will need a membership concept in the future as well (we already know that `Meeting`s will need it). So the syetem should be designed in a polymorphic way.
* To quickly access what projects a user has access to, we want to keep the `project_id` field in the memberships and **always** fill it out if the membership is somehow product related.
* `project NULL`, `entity NULL` → used to assign global roles with global permissions
* `projet NOT NULL`, `entity NULL` → used to assign project roles with project scoped + entity based permissions that apply to all entities within the project
* `project NOT NULL`, `entity NOT NULL` → used to assign entity specific roles with entity based permissions (i.e. for a specific work package)
* `project NULL`, `entity NOT NULL` → This case is currently unused and we are not considering it for now.
* The permission checks have to be adjusted:
* The current check checks for a permission on the project or globally. This check needs to be adjusted to also check that the `entity` is NULL, otherwise giving access to a single `entity`, will give access to the entire project
* Also, the check needs to be extended that we can pass in an `entity` instead of the project to the check method and for this. When the entity is bound to a project (`respond_to?(:project_id)`), we need to check for permissions on the project itself **and** on the specific entity.
* For this, we need to implement entity specifc roles ##49493
---
## ToDo List
- [x] Add `entity_type` and `entity_id` fields to the `members` table
- [x] Add polymorphic relationship, to `Member` model and ensure that only certain models can get assigned
- [x] Update `UserAllowedService` to allow checking for an `entity` as the `context` (with also checking project permissions)
- [x] Update `Authorization` module to allow querying all roles connected to an entity
- [x] Update `ProjectRoleCache` to allow querying and caching based on entity instead of projects
- [x] Update `CreateInheritedRolesService` to correctly assign `entity` attributes
- [x] Update README for permissions
- [ ] Update visible scope for projects: All projects that a user has either a direct membership on the project or any entity below the project (TBD)
- [ ] **Potential**: Add a cache for the entity based roles and allow preloading
* We already know that we will need to extend the system in the future, because other models will need a membership concept in the future as well (we already know that `Meeting`s will need it). So the syetem should be designed in a polymorphic way.
* To quickly access what projects a user has access to, we want to keep the `project_id` field in the memberships and **always** fill it out if the membership is somehow product related.
* `project NULL`, `entity NULL` → used to assign global roles with global permissions
* `projet NOT NULL`, `entity NULL` → used to assign project roles with project scoped + entity based permissions that apply to all entities within the project
* `project NOT NULL`, `entity NOT NULL` → used to assign entity specific roles with entity based permissions (i.e. for a specific work package)
* `project NULL`, `entity NOT NULL` → This case is currently unused and we are not considering it for now.
* The permission checks have to be adjusted:
* The current check checks for a permission on the project or globally. This check needs to be adjusted to also check that the `entity` is NULL, otherwise giving access to a single `entity`, will give access to the entire project
* Also, the check needs to be extended that we can pass in an `entity` instead of the project to the check method and for this. When the entity is bound to a project (`respond_to?(:project_id)`), we need to check for permissions on the project itself **and** on the specific entity.
* For this, we need to implement entity specifc roles ##49493
---
## ToDo List
- [x] Add `entity_type` and `entity_id` fields to the `members` table
- [x] Add polymorphic relationship, to `Member` model and ensure that only certain models can get assigned
- [x] Update `UserAllowedService` to allow checking for an `entity` as the `context` (with also checking project permissions)
- [x] Update `Authorization` module to allow querying all roles connected to an entity
- [x] Update `ProjectRoleCache` to allow querying and caching based on entity instead of projects
- [x] Update `CreateInheritedRolesService` to correctly assign `entity` attributes
- [x] Update README for permissions
- [ ] Update visible scope for projects: All projects that a user has either a direct membership on the project or any entity below the project (TBD)
- [ ] **Potential**: Add a cache for the entity based roles and allow preloading