Content
View differences
Updated by Klaus Zanders almost 3 years ago
We already have some work package specific permissions (i.e. `assign_versions`), but those are currently bound to a project, and are also _checked_ in the context of a project (`user.allowed_to?(:assign_versions, work_package.project)`. We also currently only have global and project specific roles.
Those two areas need to be extended by implementing work package bound roles and also checking roles related to the work package.
* [ ] Implement a `WorkPackageRole` along `GlobalRole`
* [ ] Seed the 3 `WorkPackageRole`s (Edit, Comment, View) with the permissions described in #<mention class="mention" data-id="31150" data-type="work_package" data-text="#31150">#31150</mention> in a migration into the database, and add them to seeds
* [ ] Change the permission checking system to allow passing in a `WorkPackage` and either check if the user has the requested permission by a project membership **or** work package membership (see <mention class="mention" data-id="49492" data-type="work_package" data-text="#49492">#49492</mention>)
* [ ]
## Out of scope
* We **do not** want to build edit views for the work package related roles in the first iteration. They should be seeded as defined in the FEATURE ticket and actively excluded in the list of roles
Those two areas need to be extended by implementing work package bound roles and also checking roles related to the work package.
* [ ] Implement a `WorkPackageRole` along `GlobalRole`
* [ ] Seed the 3 `WorkPackageRole`s (Edit, Comment, View) with the permissions described in #<mention class="mention" data-id="31150" data-type="work_package" data-text="#31150">#31150</mention> in a migration into the database, and add them to seeds
* [ ] Change the permission checking system to allow passing in a `WorkPackage` and either check if the user has the requested permission by a project membership **or** work package membership (see <mention class="mention" data-id="49492" data-type="work_package" data-text="#49492">#49492</mention>)
* [ ]
* We **do not** want to build edit views for the work package related roles in the first iteration. They should be seeded as defined in the FEATURE ticket and actively excluded in the list of roles