Allow dot ('.') in relation names

[matoous]

Dots (.) are great way to separate and give hierarchical structure to relation (permissions). E.g. repostiories.read or even repositories.contributors.read. As compared to _ (that is supported) they are considered word breaks and imho the semantic would be cleaner than using _ in the same place.

It would be great if Permify supported usage of "." in relation names.

Example based on single role from GCP (see roles and permissions reference):

entity user {}

entity organization {
}

entity project {
    relation parent @organization

    relation owner @user
    relation accessapproval.approver @user

    permission accessapproval.requests.approve = accessapproval.approver or owner
    permission accessapproval.requests.dismiss = accessapproval.approver or owner
    permission accessapproval.requests.get = accessapproval.approver or owner
    permission accessapproval.requests.invalidate = accessapproval.approver or owner
    permission accessapproval.requests.list = accessapproval.approver or owner
    permission accessapproval.serviceAccounts.get = accessapproval.approver or owner

    permission accessapproval.settings.get = accessapproval.approver or owner

    permission resourcemanager.projects.get = accessapproval.approver or owner

    permission resourcemanager.projects.list = accessapproval.approver or owner
}

The GCP is admittedly quite an ower-blownexample but illustrates well how . allow permissions to be structured well into namespace (e.g. resourcemanager) or sub-resources (e.g. resourcemanager.projects). Other separators could be used as well but :and#already have their own syntactical meaning so.` seems like a better choice.

[tolgaozen]

Hello @matoous, could you please explain your request in more detail? It would be great if you could do this through an example of a Permify DSL.

[matoous]

@tolgaOzen sure! I updated the issue description, would you please take a look if it's more descriptive now?

[tolgaozen]

Hi @matoous, using ‘.’ for hierarchy access can be a bit risky and might cause confusion due to its functionality. To give an example:

entity user {}

entity organization {
    relation admin @user
}

entity project {
    relation parent @organization

    permission accessapproval_requests_approve = parent.admin
}

Here, parent.admin is used to access the admins of the organization. But ‘:’ is not a special symbol in this context. If you'd like, you can open an issue regarding this. We can quickly evaluate it and add it to our roadmap.

[matoous]

@tolgaOzen good point, now sure how I missed that. In that case maybe one more thing to consider would be to allow quoting the permissions:

entity user {}

entity organization {
    relation admin @user
}

entity project {
    relation parent @organization
    relation accessapproval.approver @user

    permission accessapproval_requests_approve = parent.admin or "accessapproval.approver"
}

although this is admittedly not very clean.

[ghost]

I have this same problem... for example a relationship:

If I post to http://localhost:3476/v1/tenants/t1/relationships/write with data

{
    "metadata": {
    },
    "tuples": [
        {
            "entity": {
                "type": "organization",
                "id": "org.2WffVF27PL5VO00JcqYYhiq42m6"
            },
            "relation": "member",
            "subject": {
                "type": "user",
                "id": "acct.2WffVEDWStT0jfiBlcO9vjcwQpd"
            }
        }
    ]
}

Invalid RelationshipWriteRequest.Tuples[0]: embedded message failed validation | caused by: invalid Tuple.Entity: embedded message failed validation | caused by: invalid Entity.Id: value does not match regex pattern \"^(([a-zA-Z0-9_][a-zA-Z0-9_|-]{0,127})|\\\\*)$\"",

We tend to use these style of ids in our app to make it easier to identify some entity ID.

Is there a work around? The only thing I can think of is making a custom client which can encode/decode values... which is not really fun.

[tolgaozen]

Hello @slimdevl , yes, we have received feedback regarding this issue. It will be fixed in the next release 🙂

[EgeAytin]

Hi @slimdevl, we've noticed that your issue is slightly different from the one discussed above, so we've opened a new topic for it. You can track this issue using issue #758

[ghost]

Thanks Guy! I worked around it using custom json marshallers to modify/unmodify the IDs... Will check it out.