Closed mitjaziv closed 5 years ago
Other:
For example:
Clarify any suggestions here.
Additionally: the existing naming we have here is already good. Using “resource” is a good distinction from the more generic object. We can even say not every object (e.g. message) is a resource and get that semantic distinction between Go objects and RBAC resources in future discussions.
On Thu, 21 Feb 2019 at 10:47, Denis Arh notifications@github.com wrote:
- we will keep the system as a fallback for things that do not belong to messaging/compose
- grant/revoke follows RBAC ANSI terminology.
- resource => object, follows RBAC ANSI terminology.
- this is not a proposal, it is a done thing and mostly implemented. will throw UI over it today/tomorrow.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/crusttech/crust/issues/45#issuecomment-465896182, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOPkAVedY0GQYOc2F-_6GgyrqBRkPSLks5vPk75gaJpZM4bGD2A .
Implemented.
Changes defined today:
1. API Permission definition: API entrypoints should be under system as we are editing permissions for messaging, crm and system.
2. Current permission hierarchy:
3. Rules entity definition: value = grant|revoke operation =
object = [:"*"|]
roleId + object + operation + value