Permify is built in such a way that I

[soft willow]

Hi @novel vault, welcome to the community 👋

To check access for an endpoint, such as "search for company documents", you can adjust your model accordingly without needing to check all docs and their IDs.

Such authorization model can handle this,

entity user {}

entity organization {
    relation employee @user
    
    action search_documents = employee
}

In this schema:

• I define a user entity to represent users in our system.
• I define an organization entity with an employee relation to represent the employees.
• Also created an search_documents action within the organization entity, which is allowed for employees.

Now that we have our schema defined, we need to create the necessary relations in Permify. For example, when a user becomes an employee, you would create a relation tuple like this:

organization:1#employee@user:123

This tuple represents that the user with ID 123 is an employee of the organization with ID 1.

When a user tries to access the "search for company documents" endpoint, you would perform a permission check using Permify's API. Here's an example of how you might do this using Go:

cr, err := client.Permission.Check(context.Background(), &v1.PermissionCheckRequest{
    TenantId: "t1",
    Metadata: &v1.PermissionCheckRequestMetadata{
        SnapToken: "",
        SchemaVersion: "",
        Depth: 20,
    },
    Entity: &v1.Entity{
        Type: "organization",
        Id: "1",
    },
    Permission: "search_documents",
    Subject: &v1.Subject{
        Type: "user",
        Id: "123",
    },
    Context: *v1.Context{
        Data: data,
    }
})

if (cr.can === PermissionCheckResponse_Result.RESULT_ALLOWED) {
    // User is allowed to search for documents
    // Proceed with the search
} else {
    // User is not allowed
    // Return an error or redirect
}

This code checks if the user with ID 123 has permission to perform the search_documents action on the organization with ID 1. If the check returns RESULT_ALLOWED, you can proceed with the document search. If not, you should deny access.

At first glance this seems to solve what you want to achieve but if I missing something let me know.

[novel vault]

this solution has a problem. if I create a new endpoint, for example, "Get a list of bank transactions", then I will have to redefine the permify scheme

I saw the solution above, when access to the endpoint that outputs a list of something is indicated with "*" instead of id and the request is supplemented with context

[soft willow]

Are you referring wildcard (*) for subject type or entity type. If its for subject type it's not our roadmap for near future.

[novel vault]

For entity)

[soft willow]

Got it.

Would you against a quick call on your availability this week or maybe next week to discuss yout need? Without knowing the specific details of your use case its hard to navigate the right direction.

[soft willow]

We could also consider adding entity wildcard support, but as I said there might be better alternative

[novel vault]

I am from Russia and it is difficult for me to speak English on the phone) I'm comfortable with text

[soft willow]

No worries

could you eloborate more about your use case, and the need, specifically what you want to achieve.

[novel vault]

I am writing a backend for an online store. It includes solutions such as: working with objects of goods, delivery, payment for orders, a custom shopping cart, the ability to place orders on behalf of an employee of another company in a store, etc. This backend plans such frontend clients as: an admin panel in which employees work, can create products or, for example, view detailed information about users, including confidential (email/phone); and the part that is intended for buyers, there are mainly GET requests and the output of confidential information is minimized. The authentication account is single, which causes some difficulties in authorization