Organization rules for runs start/stop about agola HOT 10 CLOSED

@alessandro-sorint There're not enough details in this FR. Is it correct that only owners can do actions? Or is it a bug that members cannot do it. What's the meaning to be a member if you cannot do any action? Is this related to RBAC issue #13 ?

from agola.

@sgotti I think it is a bug. I can fix it: so all organization members can start/restart a run.
I will open PR.

I think your issue #13 will be useful to manage run actions permissions.

from agola.

I think your issue #13 will be useful to manage run actions permissions.

Isn't this issue talking about run actions permissions (start/stop/cancel)?

from agola.

I think your issue #13 will be useful to manage run actions permissions.

Isn't this issue talking about run actions permissions (start/stop/cancel)?

I see in the issue In future there could be the possibility to define custom roles there will be in the future the possibility to define a custom rule that can/can't do run actions with issue #13?

from agola.

@alessandro-sorint There're not enough details in this FR. Is it correct that only owners can do actions? Or is it a bug that members cannot do it. What's the meaning to be a member if you cannot do any action? Is this related to RBAC issue #13 ?

I think the current default behaviour makes sense: only owners should be able to stop / cancel / restart runs by default.
On the other side it would be nice to have an option (at organization / subgroup / project level) to allow standard (non-owners) members to perform those actions.

from agola.

I think the current default behaviour makes sense: only owners should be able to stop / cancel / restart runs by default.
On the other side it would be nice to have an option (at organization / subgroup / project level) to allow standard (non-owners) members to perform those actions.

The purpose of #13 (teams and RBAC) was to cover also such cases.
If it's too much then something simpler could be implemented (and a future implementation of #13 should migrate this simpler logic to its logic).

In such case:

• Is it ok to permit to everyone in the org to start/stop/cancel any run or there should be a filter based on branch, tag, PR (i.e. avoid anyone to stop a production deploy from master)?
• The same thing should be implemented also for tasks approval or we'll end up with users able to start/stop/cancel a run but not to approve tasks.

from agola.

I think the current default behaviour makes sense: only owners should be able to stop / cancel / restart runs by default.
On the other side it would be nice to have an option (at organization / subgroup / project level) to allow standard (non-owners) members to perform those actions.

The purpose of #13 (teams and RBAC) was to cover also such cases. If it's too much then something simpler could be implemented (and a future implementation of #13 should migrate this simpler logic to its logic).

In such case:

• Is it ok to permit to everyone in the org to start/stop/cancel any run or there should be a filter based on branch, tag, PR (i.e. avoid anyone to stop a production deploy from master)?
• The same thing should be implemented also for tasks approval or we'll end up with users able to start/stop/cancel a run but not to approve tasks.

@sgotti I think we can define the table preferences with this fields:

parent Parent
performActionCondition *When
performApproveCondition *When

• evry org/project/projectgroup can define 1 preferences; with when type we can define (branch/tag/ref) and include/exlude conditions.
• we can manage the hierarchy, for example if we define preferences for a org subgroup this will replace the org preferences.
• If preferences is not defined it will considered that the user member can't perform the action/approval.

APIs updates:

POST /orgs
POST /projectgroups
POST /projects

In the the request add this fields:

canPerformAction bool
performActionCondition *When
canPerformApproval bool
performApproveCondition *When

• if canPerformAction or performActionCondition are true the preference will be created.
• If the parent of project/projectgroup is a user the API will ignore this new fields.

In the same PR or another we can add APIs to update preferences.

PUT /projectgroups/{projectgroupref}/preferences
PUT /projects/{projectref}/preferences

the request can contains this fields:

canPerformAction bool
performActionCondition *When
canPerformApproval bool
performApproveCondition *When

from agola.

@alessandro-sorint How to implement should come after we choosed what to implement, the behavior and the logic.

from agola.

The logic is this:

• by default only the owner can perform run actions(cancel/stop/restart) and task actions(we have only accept)
• with this changes, the organization owner can add permissions for all the members, with some filter based on branch, tag, PR.
• there will be 2 kinds of permissions: run action permission and task permission.
• this permissions can be defined for organization scope, and in a hierarchical way for subgroups and projects(like secrets/variables).
• only owners can add this permissions and change it.
• the permission can be defined when the user create org/project/projectgroup or update next with dedicated API.

agola-web will change: in the org/project/projectgroup creation page add 1 check-box for run action permission with filters(not mandatory) and 1 check-box for task action permission with filters(not mandatory).

from agola.

• this permissions can be defined for organization scope, and in a hierarchical way for subgroups and projects(like secrets/variables).

secrets and variables are different. They are types that are inherited from parents.

This is instead a property. If it's going to be inherited this will cause a lot of confusion with other properties (like PassVarsToForkedPR) and the overriding logic isn't clear:

• Projects my have different branches layout and names, so an inherited options doesn't make sense.
• what happens if I change the options filters inside a subgroup?

The cleaner solution will be to just have this config per project like any other config.

That's why teams and rbac roles as in #13 were introduced. You have a team of members that have specific roles on specific projects. The inheritance of the permissions was at the level of the teams hierarchy and not at the level of the org/projectgroups/proejcts hierarchy.

from agola.