search

amplication / amplication

🔥🔥🔥 The Only Production-Ready AI-Powered Backend Code Generation
https://amplication.com
Other
15.1k stars 1.47k forks source link

Enhance the permissions view to allow for the specification of possession #3050

Open matthewadams opened 2 years ago

matthewadams commented 2 years ago

Feature description

The current permissions view does not allow the user to set possession information. Enhance it to allow for the specification of possession.

Use case

The simplest example would be that Users should only be able to view, update & delete their own User entity (I'd even argue that these permissions should be the default).

Are you willing to submit PR?

Yes I am willing to submit a PR!

matthewadams commented 2 years ago

See discord message https://discordapp.com/channels/757179260417867879/994293225370173530/995071910125781055 for working code & broad strokes for generator support. 😊

yuval-hazaz commented 2 years ago

Thanks @matthewadams I can see the need and value. We should think about it with a greater scope to include other entities and not just the User entity ( which is the simpler use case)

matthewadams commented 2 years ago

@yuval-hazaz Yes. See https://github.com/amplication/amplication/issues/3060#issue-1299916789 for possibilities.

matthewadams commented 2 years ago

The idea is that, by indicating possession, the framework would generate the enforcement of own, as demonstrated in https://github.com/amplication/amplication/issues/3055#issuecomment-1179555433

vincenzodomina commented 1 year ago

Is there news/plans for this request?

My use case for this is:

Restrict a "user" from reading all "posts" (from other users) and instead only allow him to read his own private posts.

My desired behavior would be:

In the generated grants.json file i see grants created for the user (read:own and read:any) and in the posts.controller.base.ts i see the nestAccessControl decorator referring only to "read any".

If I delete the "read:any" grant, the GET route is now forbidden in every case for the user, so it seems that the grants only control the route directly and don't interact with the query objects or check for a connected user property out of the box.