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.

* Begin of the insertion[x]End of the insertion Begin of the deletion [ ]End of the deletion Add a system to the permission system to define what types it can be assigend to.
* In a chat with <mention class="mention" data-id="80422" data-type="user" data-text="@Aaron Contreras">@Aaron Contreras</mention> we figured out that it might make sense to tie the `WorkPackageRole` to a certain module name (in this case `work_package_tracking`)
* Begin of the insertion[x]End of the insertion Begin of the deletion [ ]End of the deletion Implement a `WorkPackageRole` along `GlobalRole`
* Begin of the insertion[x]End of the insertion Begin of the deletion [ ]End of the deletion 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
* Begin of the insertion[x]End of the insertion Begin of the deletion [ ]End of the deletion Make sure, that all permissions that are described in #<mention class="mention" data-id="31150" data-type="work_package" data-text="#31150">#31150</mention> are availabe in `permissions.rb` and make sure they are properly scoped to be work package specific, so that we can easily build the forms for them later on.

## 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