Feature/41086 work package assigned capability

[ulferts]

Introduces a permission that when granted, allows a user to have work packages assigned to her/him. This replaces the flag on members assignable that previously governed the same behaviour.

This is also reflected in the role administration where the newly introduced passive permission was added to the work packages fieldset.

As this permission might be hard to understand, the ability to add explanations for a permission was introduced.

The change was made mostly so that the permission can become part of the capabilities api in the form of work_packages/assigned. Currently, this is meant to represent both the ability to become assignee as well as responsible but if necessary, this can be split up.

Because administrators should not receive this permission, a new flag is introduced for permissions to govern this which required changes to various permission queries.

When working on fixing specs, a former patch was now properly included into the previously patched file since the distinction is no longer necessary and causes errors at least when run in development mode (cost types where not displayed on cost report page).

The migration included not only replaced the assignable column but also removes role_permissions entries that are orphaned as the referenced role got removed. This should no longer happen now since the relation now has a dependent: :destroy added to it.

Lessons learned

Currently, there are various places in which permissions are derived from the originally involved tables: members, member_roles, roles, role_permissions. Those all have to be altered when the way permissions are checked changes. Additionally, this is all done repeatedly whenever a permission needs to be checked.

It might be worthwhile to calculate the active permissions into a persisted view consisting of the columns principal_id, project_id, permission which gets updated whenever the original tables are altered but after that serve as the source of truth for whenever permissions are checked.

That way, checking permissions will become very easy and performant.

Updating can the view can happen asynchronously but needs to happen whenever the original data changes. This can be done either on the database level via database triggers or via update requests issued from rails.

TODO

• Introduce new permission
• Remove assignable column
• Add migration so that every role having had assignable = true receives the new permission
• Rework the role UI form where the assignable property is modified.

https://community.openproject.org/wp/41086

[oliverguenther]

It might be worthwhile to calculate the active permissions into a persisted view consisting of the columns principal_id, project_id, permission which gets updated whenever the original tables are altered but after that serve as the source of truth for whenever permissions are checked.

That way, checking permissions will become very easy and performant.

• 1 from my side.