Custom Roles indirect role

[uncut solstice]

Hey @thorny jewel give us a few minutes to work on this 👍

[thorny jewel]

Thanks @uncut solstice !

[uncut solstice]

Hey @thorny jewel ,

We have discussed but we couldn’t understand 2 concepts over here. As far as we understood you’re trying to build custom roles;

• Is this admin role is also a custom role?
• Do you want this admin roles to access any documents read permissions without writing the relationship explicitly, if so why?

The reason I’m asking is we’re trying to understand the context

[thorny jewel]

Thanks @uncut solstice to answer the question.

1. Yes the admin role too is a custom role.
2. We want a group of users who are in an admin role to always have access to any document that is created in the system automatically.

There could be other such teams created after documents are added so we can't go back and write relationships again.

is there a better way I can model this?

[uncut solstice]

Thanks for the clarification @thorny jewel

schema:

entity role {
    relation member @user
}
entity document {
    relation reader @role#member
    relation admin  @role#member
    permission can_read = reader or admin
}```

If you actually do this every time some is assigned the custom admin role, they are gonna be able to access the document with a can_read permission.

But at the run time you need to write the data on writeDB.

For instance, you wrote following tuples;
`document:1#admin@role:member#member`
`role:admin#member@user:ryu`

Now Ryu can read the `document:1`

If you want Ryu to be able to read `document:2` on the run time once `document:2` created you need to write following tuple in to the writeDB;
`document:2#admin@role:member#member`

Also, as far as I understand  `reader`  role should have granularity based on the document itself. For instance, if you're assigned to `document:1` as a `reader` but not assigned to `document:2` as a `reader` you should only be able to read `document:1`

In other words, this custom roles feature brings some coarse-granularity. Here's how you can make it more granular.

```entity user {}
entity role {
    relation member @user
}
entity document {
    relation reader @role#member
    relation admin  @role#member

    relation assignee @user
    permission can_read = (reader and assignee) and  or admin
}```

This means in order to read a document;
- I can either have a system `admin` role (which is a custom role)
- Or I can have a system 'reader' role (which is also custom role) and I have to be `assigned` to given document (which means document should be shared with me just like what we have seen in Google Drive)

Does it make sense? Lmk 🙂

[thorny jewel]

I think I do understand, but how do I deal with this scenario?

1. two roles exist in the system viz members and admin-1
2. 1 million documents get created in the system and I write the relations document:<n>#admin@role:admin-1 for each of them so that users having the admin-1 role get access to all the docs.
3. someone creates a role admin-2 and wants all documents in the system accessible users of admin-2

If I understand by your example I'll have to write the relation for all pre-existing document document:<n>#admin@role:admin-2 , wouldn't that be very hard to keep updated?

[uncut solstice]

Make sense yes, we have an upcoming solution for this kind of problem which is not prioritized at the moment

Like the following logic;
https://github.com/Permify/permify/issues/231

It's basically a wildcard support for relationships

Instead of writing the following tuple;
document:1#admin@role:admin-1

You could be able to use wildcard;
document:*#admin@role:admin-1 which defines all the documents.

So once the admin-2 role created you would only need to write a single tuple instead of thousands;
document:*#admin@role:admin-2

Does this logic solves your problem, if so would love to hop on a call and figure out how can we prioritize this for you guys?

https://meetings-eu1.hubspot.com/fred-dogan/customer-discovery