RFD 26 - Custom Approval Conditions

[fspmarshall]

Rendered

[klizhentas]

I like the idea of proposals as a vote log and then delayed evaluation of proposals, because
client users can build their own evaluators of proposals.

I think we need more work on the proposal evaluator, how do we express the following:

• Alice can only approve requests for her team
• Bob needs at least two approvers from his team, but can nominate more as a reviewer
• Bob can approve but not override the roles proposed by Carol
• Request will suggest Alice and bob

Also, how do we query:

• Who can approve requests for this requests?

Building on your idea of access_request generators, we can define a predicate that gets evaluated on every state transition.

Default predicate (for backwards compatibility) will approve the request if there is any proposal moving it to the approved state.

We can define other predicates that take the list of proposals and define true or false - saying whether the request is approved. They can take the access request and say things liks:

; default predicate approves if there is any proposal moving it to approved state
approve_if: any(req.proposals, 'approved')

At least two people have approved:

approve_if: min_approvers(2)

At least two reviewers from my team has approved my request:

approve_if: ge(has_labels(req.proposals, user.traits.team), 2)

Nop request that lets clients implement their own logic and with it state machine will do nothing, never approving any request

approve_if: nop()

This borrows the same idea from predicates, we'd need to define predicates that work out of the box.

[a-palchikov]

so far, a couple of typos.

[awly]

Can this be merged, since the implementation is merged already?