simple Permify POC

[worldly ember]

Hi @shadow lantern , thanks for sharing your use case. In Permify, we don't have an update operation for schemas. The only way to change the schema/policy is by creating a new one and managing the versions with schema_id. So yes, for permission changes, you need to create a new schema and structure a proper migration flow to overcome inconsistencies.

Could you check out the following page to see how to manage these changes within Permify: https://docs.permify.co/docs/use-cases/custom-roles/? If you believe this wouldn't be sufficient, we'd love to learn more about your use case and have a quick chat to assist and brainstorm ideas to overcome this.

[shadow lantern]

Thanks for the detailed info!

Doing a quick scan of the custom roles page. This might satisfy my use case. Although I'm really starting from scratch with both my knowledge and using this type of service around authorisation. 😅

I will have a better understanding once I've gone through the basis steps according to the documantation and a working poc with permify.

I'll revist this thread once I'm there.

[worldly ember]

Great! Feel free to ask any questions you have ✌️

[shadow lantern]

I've got a question regarding the relationships.

I'm basing my poc off the Notion example: https://docs.permify.co/docs/getting-started/examples/notion/

I'm a bit confused as to the "engineering_team" notation, is it an id?

workspace:engineering_team#owner@user:alice

So this would be entity : id # relation @user : name (user name from db)

Would this line of thinking be correct or is there a different pattern?

---

From my database, I'm now able to generate a schema on the fly:

entity user {}

entity Todo {
  relation editor @user
  relation admin @user

  permission create = admin
  permission read = admin
  permission update = admin
  permission delete = admin
}

Todo:all#editor@user:e4b4552a-7bf5-4a2c-a284-3bff0dc59dc7
Todo:all#admin@user:e4b4552a-7bf5-4a2c-a284-3bff0dc59dc7

In this instance Todo is a route in an application. I want to give the ability to users to have a role and that role dictates what they can do via the permissions.

Here only the Admin role has permissions set. (see images).

Is what I have correct? Since I'm not filtering on results from the db. But rather restricting whether someone has access to a page. All should be fine?

Thanks

[worldly ember]

Hi @shadow lantern, so the engineering_team is an id in the notion example. And you’re mostly correct about the form of the tuple, just one thing: it should be identifier after user so its “@user:id” not “@user:name”. So, the correct tuple form is: ‘entity:id#relation@user:id’.

Regarding the schema, it seems totally legit to me. I just don’t understand the ‘Todo:all’ parts in the tuples. If you want to assign/write the respective relation and user to all todo items, then you should explicitly define them with IDs, since we don’t have a wildcard ‘all’ keyword.

[shadow lantern]

Thanks for the reply, appreciate it!

Regarding the schema, it seems totally legit to me. I just don’t understand the ‘Todo:all’ parts in the tuples. If you want to assign/write the respective relation and user to all todo items, then you should explicitly define them with IDs, since we don’t have a wildcard ‘all’ keyword.

As you say, I'm using all as a wildcard. As I am not restricting the user to specific ids. For example, if we imagine a products table. Usually a product admin or product editor would be managing the products. They would want to see all products. I don't have any use case, where I would want to hide particular products from a user. Hence the "all" wildcard.

Should I be using * in this case. Would it be more idomatic?

[shadow lantern]

I've also got a question on snap_tokens.

Imagine the following scenario. I generate a new schema. I get back the schema_version.

I then create new relationships, I get back a new snap_token.

I then change the schema again and get a newer schema_version.

When I do a permission check. Do I supply just the schema_version or do I also supply the snap_token?

My understanding would be that the changes I did in the last schema, would be further in-time than when the cache was snapshotted with snap_token.

Is this correct? Thanks

[worldly ember]

Understood, generally our check based approach designed for item based checks. In this scenario you might consider consider treating the product table as an item, such as creating a respected entity related with it (maybe table, maybe solely products_table) then create a tuple according to it. Since I don't know the exact details its hard to tell the best practise but hope you get my point in this scenario.

[worldly ember]

Exactly, so after you obtain the snap token, you made a change in the schema. This causes the most recent change to be further ahead in time compared to the cache. It's worth mentioning that if you don't specify a schema_version, the Permify engine will retrieve the latest schema and then operate accordingly.