Can I use top-level operators in can/cannot rules?

[jnardone]

I'm trying to track down some failures when we went from 3.2.0->3.4.0 (well, 3.3.0 is where the breakage is, likely with the bump of sift). Our automated tests have some failures and the rules they're failing on seem to follow a specific pattern.

  can('read', 'thing', {
    $and: [{ thing: { $ne: 50 } }]
  });

Namely: it appears any rule that has a top-level operator like this in the conditions section. We do both $or and $and and these worked in 3.2.0 but fail now.

So:

• is this a syntax that should work?
• if not, do you have any suggestions on how this would be expressed? We want to append additional things to compare against the resource row

[stalniy]

Casl has never had documented support for $or and $and. If use them you make your life much more complicated. Why? because there is a built-in behavior which allows to use $and and $or under the hood.

All direct rules (specified by can) are logically OR-ed. So the next 2 samples are equivalent:

// 1st
can(‘read’, ‘thing’, { 
   $or: [{ prop1: 1, prop2: 2 }]
})  

//2nd
can(‘read’, ‘thing’, { prop1: 1 })
can(‘read’, ‘thing’, { prop2: 2 })

And all inverted rules (specifies by cannot) are logically AND-ed.

This allows fine grained control on what to allow user to do. With more complicated rules, things become more complex.

First, try to redefine rules in suggested way. sift now supports custom query creation, so in 4.x you won’t be able to use $and and $or operators

[stalniy]

This is documented in “combining abilities” section here - https://stalniy.github.io/casl/abilities/2017/07/20/define-abilities.html