Content
View differences
Updated by Jens Ulferts over 5 years ago
### Use cases
* Get all projects in which an action can To be performed for a user
* Get actions a user can perform inside a project (e.g. have a work package assigned - which is not really an action)
* Get all users allowed a certain action (this is currently carried out by specific end points, e.g. available\_assignees)
* Knowing why an action cannot be carried out without having to trigger the action first (e.g. moving a work package to a project within a subproject board -> highlight eligible columns and disable the rest.)
* ?Deduce the project menu -> depending on the actions, menu items can be displayed or hidden?
* Will adding a role to a user allow the action to assign work packages to the user. This should be answered before the role is assigned.
* For every resource (e.g. work package, user) -> what are the allowed actions? specified
### Considerations
* Who is allowed to query for actions, e.g. all actions another user can perform
* Performance: calculating the complete set for a larger amount of users/projects and rendering potentially long lists is work
* How to deal with existing action links in already published resources. Currently we mix resource and action links which is confusing.
* What is the correct granularity for the actions and how to have some standard (e.g. CRUD). For work packages, the actions are more granular compared to e.g. news.
### Notes
* Rather a list of actions than a list of the permissions that exist in the backend. Reason: Even tough a permission might be set, there can be additional conditions not met that prevent an action to be active.
* Idea: Instead of not displaying actions that are not available, render all the actions but flag them to be unavailable. Add a "reason" property to note why an action is unavailable. Reason: That way, the frontend can display the reason why an action is unavailable to the user.
* Get all projects in which an action can
* Get actions a user can perform inside a project (e.g. have a work package assigned - which is not really an action)
* Get all users allowed a certain action (this is currently carried out by specific end points, e.g. available\_assignees)
* Knowing why an action cannot be carried out without having to trigger the action first (e.g. moving a work package to a project within a subproject board -> highlight eligible columns and disable the rest.)
* ?Deduce the project menu -> depending on the actions, menu items can be displayed or hidden?
* Will adding a role to a user allow the action to assign work packages to the user. This should be answered before the role is assigned.
* For every resource (e.g. work package, user) -> what are the allowed actions?
### Considerations
* Who is allowed to query for actions, e.g. all actions another user can perform
* Performance: calculating the complete set for a larger amount of users/projects and rendering potentially long lists is work
* How to deal with existing action links in already published resources. Currently we mix resource and action links which is confusing.
* What is the correct granularity for the actions and how to have some standard (e.g. CRUD). For work packages, the actions are more granular compared to e.g. news.
* Rather a list of actions than a list of the permissions that exist in the backend. Reason: Even tough a permission might be set, there can be additional conditions not met that prevent an action to be active.
* Idea: Instead of not displaying actions that are not available, render all the actions but flag them to be unavailable. Add a "reason" property to note why an action is unavailable. Reason: That way, the frontend can display the reason why an action is unavailable to the user.