Add router role with automatic proxying of the crud API via public functions about crud HOT 5 CLOSED

Having to do all the boilerplate you list is a problem. But I see a better solution from what you propose.

I think client libraries should call "crud.x" directly, without any wrappers. For this to work, the crud module should register itself in a global variable with the same name as the module name when first loaded. Then it will be possible to call "crud.x" directly.

from crud.

This issue may be closed, all changes are implemented.

from crud.

@knazarov I will accept either of these solutions, but exposing the whole module seems to be less safe than a list of proxy functions.

from crud.

@akudiyar exposing the crud functions as a global variable is not enough for the client to be able to call them. The client should still have permissions to call those functions. And those permissions must either be explicitly granted, or the user should have execute permission on the universe.

If you need granular access control, this is not something I will expose through the data access API. Instead, I propose to add full RBAC to the enterprise edition of this module. The data access API itself should not care whether you have RBAC or not. It should be an implementation detail.

Of course, users are free to roll out their own access control if they want to. For this, they would need to wrap functions as you propose.

from crud.

@akudiyar Is there anything else on the topic you want to be implemented aside of PR #58 (released in crud 0.3.0)?

from crud.