there is a prototype for decorators on fields: https://github.com/authzed/spicedb/pull/202, but it was never developed passed that stage due to a lack of need

there is also a flag:

--http-enabled

We are processing our schema into classes in PHP so we don't have to manually transpose relationships and permissions. I created https://github.com/alsbury/spice2json based on PoC #657 to create a JSON document which get's us close. But now I am embedding metadata in comments to get around the lack of decorators. If PR #202 were completed, would it be accepted?

likely, but there are still some open questions around it that need to be answered, particularly about how annotations are defined

That makes sense. Sounds like I'm better of finding my own solution for now. Thanks!

yeah, I'd say stick with comment parsing for now

maybe even use a

@whatever

format in the comment

and then, if/when we have them ready, you could just copy them out

We were planning on using PHP docbloc parser

it would also be helpful to have your fill in your use case as a comment on that PR

might inform the feature

Ok, I'll do that

this could be due to a number of factors

touch

seems to delete + create a relation - is there something that automatically removes the

deleted

relation rows from the db (maybe a cleanup process that runs every once in a while? - or is that something I should be setting up) if I used

touch

a lot, it might lead to the number of rows growing a lot

there is an automatic GC process that should run every few minutes

the process would get rid of the deleted rows from the DB?

after they pass the GC window, which is typically 24 hours

oh nice, that's great. thank you

there is also a flag

http enabled

I am using user defined role approach as explained in the blog, I am trying to create hierarchy of user defined group, If Role has any access its supervisor roles should have same access like below

definition role { relation assigned : group relation supervisor : role permission perform = supervisor + supervisor->perform } definition resource { relation performer : role#assigned permission perform = performer + (performer -> perform) }

It is not working, can you suggest what need to be improved here

supervisor

will point to a role

not the user's assigned to the role

Gottcha, relation supervisor : role. should be changed to relation supervisor : role#assigned

yeah

we have some playground improvements coming down the pipeline to make this easier to debug

That would be awesome !

Hi guys, do you have any best practices or reference patterns to how best to integrate a permissions system like spicedb into a search use case? like we have a use case where a user can potentially have access to millions of resources, we can fairly easy define a schema that defines the resources the user can access, but we also have a search page where they can filter on properties of those resources, which can be hundreds per resources and we would like to keep out of the permissions system. But what would be best way to implement the intersection of the filtering and permissions, when the number of results can be high? if that makes sense