Employee -> Manager Level 1 -> Manager Level 2 -> Manager Level 3

you'd have to define the different levels as different object types

there isn't a way to say "walk until"

or use different relations

direct_manager

vs

indirect_manager

or somesuch

Sounds good, thanks !

I have requirement, There is a Group Account (AAA) and there are many Account under each Group Account, Accounts are like AAA_2222, AAA_3333 etc. There are many members under each account , Naming conventions are always like this, __. I have to pull all the members under Group Account (AAA) .

you can read all the members if relationships exist

And use Parent relationship with Member -> Account -> Account Group ?

SpiceDB isn't a general-purpose graph database

it can answer "does this subject have this permission on this object?"

it can answer "what subjects have this permission on this object?"

it can answer "what objects does this subject have permissions on?"

but it isn't good at answering arbitrary graph queries unless you phrase them in the above terms

I get that, I was wondering if we establish a parent child relationship in above example then , run query for read the members as Joye suggested

you can use LookupSubjects to do so

or LookupResources if the opposite way

but it isn't necessarily the best idea

👋 Hey all - I'm learning about the gRPC API and discovered PERMISSIONSHIP_CONDITIONAL_PERMISSION https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.CheckPermissionResponse.Permissionship What does that mean? Also, are the meanings of those enums defined somewhere? Thanks!

Second question - what's the recommendation for modeling attributes? For example: user A can only see post B if B has a privacy setting of PUBLIC. I found a related article that seems more focused on dynamic checks, vs a state value like this https://authzed.com/blog/caveats/

that value is a new possible value that can be returned when a result is subject to caveats, which were officially launched (in experimental) yesterday. If you're not using caveats, it can be safely ignored.

we should add the appropriate docs for those values here: https://github.com/authzed/api/blob/main/authzed/api/v1/permission_service.proto#L269

i'll open an issue

https://docs.authzed.com/reference/caveats describes it in more detail

there are a number of ways to accomplish this, the most direct one would probably be allowing for

users:*

to be bound to a reader relation

example: https://play.authzed.com/s/sSFoAu8EIFOt/relationships

documentation issue for your records: https://github.com/authzed/api/issues/48

I'm not sure what you mean by your example - I just see that a document can be viewed by all users. Here's a modification of that, with fictional syntax in comments to help explain what I'm trying to accomplish

definition user {}

definition document {
    // attribute privacy: String
    relation reader: user | user:*
    permission view = reader // and privacy = "PUBLIC"
}

adding

user:*

when the document is privacy would grant access to any user