Category

User level API features/changes

Describe the feature you'd like to request

Some users (e.g. this Slack thread) want the ability to remove an entity from an Entities object.

This is a subtle operation because Entities maintains the TC (transitive closure) of the parent relationship. Suppose your Entities contains the following graph

      Group B
     ^
    /
   /
Group A
  ^
   \
    \
    User

The Entities also includes the information that User is in Group B, even though the input entity data didn’t directly say so.
Now the user says to remove Group A. Obviously this means to also remove the User->A and A->B edges. Does it mean to remove the User->B edge as well?

• Arguably yes, because if A didn’t exist, User wouldn’t be in B in the first place
• But also arguably no, because some users may find it surprising that removing Group A changes the in relationship for User and Group B

The original requester for this feature, in the Slack thread linked above, feels that the User->B edge should be removed, which is also arguably the correct answer. (TC is an implementation detail of Cedar, and removing the User->B edge preserves the mental model that Cedar traverses the graph each time to evaluate in.)

If we do want to remove the User->B edge in the above example, as an implementation detail Cedar needs to keep some track of the pre-TC entity graph, in order to distinguish this case from the case where there is (also) an explicit User->B edge. It might or might not be sufficient to keep a flag on each edge indicating whether it is an "explicit" or "implicit" edge. (Haven't thought about whether we need to distinguish different "levels" of implicit edge, especially in the case where there are multiple sequential removals and/or additions from the entity graph.)

One way to dodge the issue above and still provide value is to only allow the easy case of removing a leaf node from the graph -- an entity with no incoming edges. So, allow removing User but not Group A or Group B in the above example. The original requester in the Slack thread linked above said this would be sufficient for their use case.

Describe alternatives you've considered

There are a few alternatives discussed above.

Additional context

No response

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change