844600078504951838 #spicedb

Channels

Joey

12/13/2022, 7:12 PM

permission members = bearer

Joey

12/13/2022, 7:12 PM

and walk to that

yetitwo

12/13/2022, 7:13 PM

and my colleague had modeled things as

definition role {
  relation bearer: user
  permission assume: bearer
}

and then was defining the object-level permissions in terms of walking to that

assume

yetitwo

12/13/2022, 7:13 PM

is there a reason to prefer one approach over the other for this sort of transitive thing?

Joey

12/13/2022, 7:15 PM

you should always use a

permission

if you can, to avoid needing to change it later if you need to add anything to it

Joey

12/13/2022, 7:15 PM

as for

#assume

->assume

, you should use

#assume

unless you're using the role for something else

Joey

12/13/2022, 7:16 PM

if you anticipate needing to walk to another part of the role, then you should use it via an arrow

Joey

12/13/2022, 7:16 PM

but either is fine

Toi

12/13/2022, 7:27 PM

Is it possible to combine different permission operations?

permission x = (a + b) & c

Joey

12/13/2022, 7:41 PM

yes

Joey

12/13/2022, 7:41 PM

just like that

jzelinskie

12/13/2022, 7:42 PM

yes, although I will warn that intersection and negation make things slower. we recommend to always try to be additive. if you can write something that only uses +, it'll be fastest

Toi

12/13/2022, 7:44 PM

In my case, for example, in order to view an employee you need to have a "permission that allows you to view direct reports" AND you must "be the leader of that employee""

Toi

12/13/2022, 7:45 PM

Is there a workaround for that using only unions?

Joey

12/13/2022, 7:47 PM

there are, but they are slightly more difficult to reason about

Toi

12/13/2022, 7:50 PM

As much as I like a clean and readable model, I guess performance in this case is more important 😅

Joey

12/13/2022, 7:50 PM

I'd start with the intersection

Toi

12/13/2022, 7:55 PM

How come? This is my model so far:

definition company {
    relation employee_viewer: permission_group#membership
    relation employee_direct_reports_viewer: permission_group#membership
    permission view_direct_reports_employees = employee_direct_reports_viewer
    permission view_employees = employee_viewer
}

/** employee represents an employee. */
definition employee {
    relation is_self: employee
    relation parent_company: company
    relation leader: employee
    permission view = is_self + parent_company->view_employees + parent_company->view_direct_reports_employees & leader
}

/** permission_group represents a permission group. */
definition permission_group {
    relation member: employee
    permission membership = member
}

Toi

12/13/2022, 7:56 PM

So in order to have the "view" permission on an employee you need to have the view_direct_reports_employees with the parent company AND also by the leader of that employee

Toi

12/13/2022, 7:56 PM

Does it make sense?

Joey

12/13/2022, 7:57 PM

yeah

Joey

12/13/2022, 7:57 PM

so the way to change it would be

Joey

12/13/2022, 7:57 PM

to have

leader

just point to

parent_company#view_direct_reports_employees

Joey

12/13/2022, 7:58 PM

likely rename

leader

too

Joey

12/13/2022, 7:58 PM

but that would combine the two together without an intersection

Toi

12/13/2022, 8:01 PM

Not sure if I understood correctly. Don't I still need an intersection?

pdow

12/13/2022, 8:02 PM

Hi all! Quick question on caveats: do they / are they planned to allow accessing relationship values? Basic use-case: I want to lookup resources by a permission, but limit the set to those resources where e.g. the relationship

parent

is equal to some ID passed in at runtime. Or would I need to duplicate the

parent

field to the "caveats data" (not sure what the right term for that is) when writing the relationship?

Toi

12/13/2022, 8:06 PM

An employee might be a leader of another employee and not have a view permission on it (that's a valid case). So it needs both the view_direct_reports permission and the leader relation in order to view

Joey

12/13/2022, 8:06 PM

right, but you could only write a relationship IF they are a leader as well

Joey

12/13/2022, 8:06 PM

but then you need to update two relationships when someone is added or removed as a leader