v0.12.0.alpha.1

Full Changelog: https://github.com/cmmoran/keto/commits/v0.12.0.alpha.1

• feat: nested arbitrary depth traversals
• feat: subject == object ( this.equals(ctx.subject) ) and support for this syntax at any depth
• feat: support for multiple binary/unary boolean operations within subject-set rewrite definitions
  • current parser only supports single comparison within a traverse statement. this release updates the parser to allow multiple "checks" under the same traversal context. Example:

related: {
  foo: Foo[]
}
permits = {
  allows: (ctx: Context): boolean =>
    this.related.foo.traverse(f => {
      f.related.bar.includes(ctx.subject) ||
      f.permits.allows(ctx)
    })
}

• feat: added global semantic support for Intersections (to support currently-supported Unions).
  • current support for unions requires ALL entities to "implement" a relation in the case that a relation is "typed" to a Union type. This release supports "intersection types" that require only one member of the intersection type to implement the relation in question during a traversal.
• feat: Simplified checks where the subject is expected to be a subject-id even though it was specified in a tuple as a subject-set. Ex:

Permission:admin-permissions#can_edit@User:Tom
Permission:admin-permissions#can_edit@Tom

The above tuple specifies two very different things. In the first, User:Tom is actually a subject-set with the relation of <blank> so canonically it could be fully expanded to: Permission:admin-permissions#can_edit@User:Tom#. This is unlikely to be the intent of the tuple creator. The second scenario defines Tom as a subject-id. Performing a check with the two above criterion will yield differing results unless BOTH tuples were added to the system. In the case of the first tuple, checks involving the subject-id Tom will return false. In the case of the second scenario, checks involving the subject-set User:Tom will also return false. This release normalizes the return values of this check by verifying that the ID in question, in this case Tom is exactly equal to the ID that was specified in the defining tuple.