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 `~~project NULL~~`~~,~~ `~~entity NOT NULL` NULL~~` → This ~~This case is currently unused and we are not considering it for now. 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
* 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
* 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