Hi all 👋 I have a schema like below. I would like to query all assigned roles to a group:

yaml
definition tdesk/user {}

definition tdesk/group {
    relation member: tdesk/user
}

definition tdesk/role {
    relation assignee: tdesk/user | tdesk/group#member
}

definition tdesk/perm {
    relation allow: tdesk/role#assignee
}

and my relation_tulple table is like below:

yaml
namespace     object_id       relation   userset_namespace  userset_object_id     userset_relation
tdesk/role,   admin,           assignee,     tdesk/user,   emre,                   ...
tdesk/group,  devx,            member,       tdesk/user,   vural,                  ...
tdesk/perm,   ticket_read,     allow,        tdesk/role,   admin,                  assignee
tdesk/role,   admin,           assignee,     tdesk/group,  devx,                   member
tdesk/role,   admin,           assignee,     tdesk/group,  agent,                  member

I would like to get answer for the question "list a user's groups". How can I get achieve this using Go SDK?

Okey I think I found the anwser like this:

go

    resp, err := c.LookupResources(context.Background(), &pb.LookupResourcesRequest{
        ResourceObjectType: "tdesk/group",
        Permission:         "member",
        Subject: &pb.SubjectReference{
            Object: &pb.ObjectReference{
                ObjectType: "tdesk/user",
                ObjectId:   "vural",
            },
        },
    })

    if err != nil {
        log.Fatalf("failed to LookupResources: %s", err)
    }

    for {
        lookupResp, err := resp.Recv()
        if err != nil {
            log.Fatalf("failed to lookup: %s", err)
        }
        log.Println(lookupResp.String())
    }

@Jake Do you think you'll have 15 minutes for me later today or sometimes on Monday?

I'm looking at the caveats blog post: > Requests that check permissions (e.g. CheckPermission, LookupResources, LookupSubjects) and write relationships can provide a context which is a set of key-value pairs that are the named parameters passed to the caveats encountered while processing the request. Here’s an example of a CheckPermissionRequest providing such a context. It seems to indicate that there is a

context

field on

WriteRelationships

, but I'm not seeing that (https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.WriteRelationships). Is there something I'm missing?

its on each RelationshipUpdate

ContextualizedCaveat optional_caveat = 4;

under

Relationship

because its per relationship

got it - that makes sense. going back to a previous conversation - is there any performance penalty for sticking arbitrary metadata into the caveats? i'm wondering if this could be used instead of the

watch_metadata

idea i was proposing for audit information, with the understanding that it's a bit of a hack and outside of the intended use case. for our purposes, we'd probably be putting

request_timestamp

and

authorizing_user_id

into the field.

its been an idea raised, but caveats do add overhead, so I wouldn't use them to store random metadata right now

okay, that's good to know

we have another approach in flight with sidebanding that should give us what we need for audit

I should also note that as it is a new, experimental feature, we haven't taken a lot of time to fully optimize them yet

but yeah, we might end up just reusing the same context for metadata too

I need to create Schema for below permission model

An organization has employee and Manager. Employee has confidential and public data. Employee can view, edit and access his data. Employee's direct manager can view and access his/her confidential data. Anyone in organization can view anyone's public data data. definition employee { relation direct_manager: employee permission access = direct_manager } definition confidential_employee_data { relation owner: employee permission own = owner permission access = owner + owner->access } definition public_employee_data { relation owner: employee relation viewer: employee:* permission own = owner permission view = viewer } Test Relationships confidential_employee_data:jake_address#owner@employee:jake employee:jake#direct_manager@employee:jimmy confidential_employee_data:david_address#owner@employee:david employee:david#direct_manager@employee:peter public_employee_data:david_name#viewer@employee:* public_employee_data:peter_name#viewer@employee:* public_employee_data:david_name#owner@employee:David

is there any better way to achieve the same

is there one universal organization?

yes

so a few things: 1) why the

own

permission? doesn't seem to be used anything 2) if "Anyone in organization can view anyone's public data data.", then a wildcard is fine, although you might just not need a permission check at all unless you see this changing

own is combination of edit + delete , used it to simplify

can we use just one document type instead of 2 public and confidential or is it okay

yes

you just need to track it yourself

you'd make

relation viewer: employee | employee:*

and only write the wildcard for public ones

just need to be careful in doing so

hmmm I see , so if i want to be extra cautious it is okay to have 2 document type.

sure

Is there any way to restrict the access after specific level of hierarchy, like Employee , supervisor should have view permission but supervisor's supervisor should not be, this could be dynamic, like restrict after 3 level or 4 level?

Just to simplify, Manager Level 1 and Manager Level 2 should have access on employee but not manager level 3?