I don't need the relation types, or permissions rules, just the names

My first thought was to write a Go program using https://github.com/authzed/spicedb/tree/main/pkg/schemadsl/compiler. I've never written Go before, so wasn't sure if there was an easier path.

there have been a number of requests for this kind of feature. we plan on adding a reflection API of some kind, but someone did PoC this too: https://github.com/authzed/spicedb/pull/657

Say you have this schema:

definition subject {
    relation viewer: user
    permission view = viewer
}

definition resource {
    relation subject: subject
    permission view = subject->view
}

and you create multiple relationships between subject and resource through the resource

subject

relation:

resource:r1#subject@subject:s1
resource:r1#subject@subject:s2
resource:r1#subject@subject:s3

subject:s1#viewer@user:u1
subject:s2#viewer@user:u1

how do you ensure that for a user to have the

view

permission on the resource the user is a

viewer

of all the subjects of the resource?

so in the example user

u1

should not have the

view

permission on resource

r1

since it is not a

viewer

of subject

s3

you cannot, currently

you want this proposed operator: https://github.com/authzed/spicedb/issues/597

Thanks!

My question is more in the sense that there is a desynchronization between the authorization service and the business services. How to manage synchronization when there is a down time for example ?

either have your systems fail to write to both if one fails using a transaction+rollback, or keep a state in SpiceDB and compare

Can

WriteRelationships

fail partially? If so, do we end up in a situation where only some of the relationships are written or are all relationships not committed when there's a write error?

no

if it does, that's a bug

the API guarantees that either all relationships are updated or none

and all precondition checks occur as part of the transaction as well

note that this doesn't really apply on memdb, which isn't designed for prod use

ok. Does spicedb have transactions? If I wanted to update relationships, by first deleting all relationships with a filter and then writing the new relationships, could I rollback at any point without having to manually restore the old relationships?

filters are only supported on DeleteRelationships

if you want to delete relationships in WriteRelationships individually, you can do so

it would be recommended to read the ones you want to delete, then add them as preconditions to the WriteRels call, along with deletes in there

ok, thanks

how do preconditions work? Is it applied as a one to one mapping to the relationship updates?

they are specified alongside the updates; you state whether a relationship should exist or not exist as a precondition

if any fail, the whole operation fails

Hi again, I came up with a different schema to implement our app modules. My idea is having the same ID for all modules and a module specific permission for each module. I think that will better suit our needs as we will have only a small number of modules and if we introduce new modules later, we just change the schema and that's it, without the need to migrate the folder relationships (as the ID will not change). However, it feels a bit like cheating as the ID will be the same. Any thoughts on whether this is a good idea or not are welcome. definition folder { relation reader: usergroup relation editor: usergroup // same module ID used for all modules relation shown_in_any_module: module // direct children only relation direct_child: folder permission edit = editor->member + organization->admin permission read_artifacts = reader->member + edit permission traversable = read_artifacts + direct_child->traversable // permissions for module A permission edit_in_a = edit & shown_in_any_module->a_user permission read_in_a = read_artifacts & shown_in_any_module->a_user permission traversable_in_a = traversable & shown_in_any_module->a_user // permissions for module B permission edit_in_b = edit & shown_in_any_module->b_user permission read_in_b = read_artifacts & shown_in_any_module->b_user permission traversable_in_b = traversable & shown_in_any_module->b_user } definition module { // module ID is identical for all modules, relation is specific for each module relation has_licence_for_a: user relation has_licence_for_b: user permission a_user = has_licence_for_a permission b_user = has_licence_for_b }

(first of all i'm loving authzed) i'm having trouble converting from playground workflow to zed cmdline. What's the requivalent of zed schema read for

zed relationship read

command, it wants some argument. I can't find an example in docs or make sense of the source code

Part of the team is kubecon this week so we may be slow to answer - apologies in advance 🙏🏻

I have another question: Is it possible to validate the schema (like validate in the ZED tool) via the GRPC Api? If not, would it be possible to add this in the future? We want to deploy the schema via the API and validate it beforehand.