State Change Permissions?

[pdfowler]

We have several domain models that support a status field, and business rules which control what transitions are allowed in each state, all of which can be modeled with a basic state machine. My current understanding of the CASL api says that specifying permissions for State Machine transitions is not possible using the core API. I'm posting this to see how others have approached the state machine problem, see if this has been considered (or built, we're still on v3 😬), or if not, propose an api that would fit nicely with the project.

State Machine Problem: Controlling Status Transitions

What I see missing in CASL is the ability to specify a target state for permissioning, ie: I can define permissions for changing a specific field, but I cannot define permissions for setting a specific field to a specific value. While we have many more statuses and conditions on each transition, the scenario can be simplified to the "post" model used elsewhere in the docs. For the sake of explanation, I propose adding a "status" field to the Post model, with the hope of defining the following simple state machine:

status: 'draft' --> status: 'published' --> status: 'archived'
               \--> status: 'discarded'

I'm currently playing around with modeling this via a custom action, "transition," and (ab)using the fields prop to serve as a proxy for the target state. It looks like this:

allow('transition', 'post', ['published'], { status: 'draft' })
allow('transition', 'post', ['discarded'], { status: 'draft' })
allow('transition', 'post', ['archived'], { status: 'published' })

// checked via:
const draftPost: IPost = { status: 'draft' };
can('transition', draftPost, 'archived'); // draft -> archived: false
const discardedPost: IPost = { status: 'discarded' };
can('transition', discardedPost, 'archived'); // discarded -> archived: false
const publishedPost: IPost = { status: 'published' };
can('transition', publishedPost, 'archived'); // published -> archived: true

which will work fine, but feels like a misuse of the api. This feels like a common problem, that I would ...

Proposed API:

I propose extending how "field" permissions are checked/calculated, and allow for objects to be passed in the fields place to define specific transitions. Continuing the scenario above, this would look like:

// Rule Definition (allow = AbilityBuilder.can)
allow('update', post, { status: 'published' }, { status: 'draft' }) // draft -> published
allow('update', post, { status: 'discarded' }, { status: 'draft' }) // draft -> discarded
allow('update', post, { status: 'archived' }, { status: 'published' }) // published -> discarded

// checking
const draftPost: IPost = { status: 'draft' };
can('update', draftPost, { status: 'archived' }); // draft -> archived: false
const discardedPost: IPost = { status: 'discarded' };
can('update', discardedPost, { status: 'archived' }); // discarded -> archived: false
const publishedPost: IPost = { status: 'published' };
can('update', publishedPost, { status: 'archived' }); // published -> archived: true

The biggest drawback to this approach (aside from any technical considerations) is the readability/DX, since the last arg (conditions) is the current value, while the second to last (fields) is the target, which essentially reverses the natural transition order. In writing the example, I got tripped up a few times and added the transition comments on each line of the definition.

Would love to hear people's thoughts on this topic

[stalniy]

casl was not designed to support state machine flows. But I see 2 options which you can use:

1. Make a custom library by yourself based on @ucast library
2. use actions to represent the initial status state:

allow('publish', post, { status: 'draft' }) // draft -> published
allow('discard', post, { status: 'draft' }) // draft -> discarded
allow('discard', post, { status: 'published' }) // published -> discarded

Using fields level permission to represent the initial state is a bit weird and I think is the wrong way. The best one, obviously is to built a specialized library for this:

state('status', (transition) => {
  transition("draft", { to: ["published", "discarded"] });
  transition("published", { to: ["discarded"] });
  // etc
})

This is business logic related stuff which very likely does not depend on user permissions and that's why should be implemented separately IMO

[pdfowler]

@stalniy Agree on all points and thanks for the pointers to other options. The reason this business logic is getting mixed in with user permissions was abstracted out of my initial writeup. In our case, different user roles in our system have different permissions around specific transitions. To extend the Post example, a user with the "manager" role can "publish" a draft on behalf of someone else, but someone with an "editor" role cannot.

From a DX perspective, we've embraced the can(action, subject, fields) syntax and would love to keep a cohesive approach. As you point out, using actions to represent the initial status state is much cleaner and understandable for both writing and consuming the rules. I'll start there and then look into whether building a custom library will be necessary.

Many thanks! Love the library 👍