Feature/own rbac implementation

[mitjaziv]

• renamed Team to Role (this affects multiple systems)
• moved Permission API from messaging to system
• update Rules to use Roles instead of Team
• extended Rules functionality with function working on complete RoleID scope (not just roleID/resource)
• added permissions rest and service
• fixed code generation for system/requests (receiver name has now 2 chars, so it does not conflicts with request parameter name)

Permission API

/rbac/{roleID}
/rbac/546345654363/rules
        POST -> [ APPEND rules
            { object: "messaging:channels:*",  operation: "update", permission: "GRANT" }
            { object: "messaging:channels:1",  operation: "update", permission: "REVOKE" }
            { object: "messaging:channels:2",  operation: "update" } <<<--- removes
            { object: "system",                operation: "organisation.create", permission: "GRANT" }
            { object: "system:organisation:*", operation: "update",           permission: "GRANT" }
            { object: "system:organisation:*", operation: "delete",           permission: "GRANT" }
            { object: "messaging:channel:*",   operation: "update.name",      permission: "GRANT" }
            { object: "messaging:channel:*",   operation: "update.topic",     permission: "GRANT" }
            { object: "messaging:channel:*",   operation: "members.manage",   permission: "GRANT" }
        ]
        GET -> returns all defined permissions for specific role 
        DELETE -> remove all define permissions for specific role

Role functionalities are in former Role API former Team API

[titpetric]

This team - role rename ignores the approach suggested in #34 and reiterated in #45 - as it’s already done I have no objections to the merge, but please keep in mind that this could have been a one line documentation fix instead of a wider codebase refactor (with no discussion).

[darh]

Question: Why remove the scopes endpoint? How do you get available scopes from the API?

this will be handled by the UI.

[darh]

I agree. But POST for rules endpoint is appending (or overriding existing rules)

[titpetric]

Would just changing the method to PATCH be more appropriate then? As it was laid out with resource as the filter, the request was intended to update the complete set of permissions for a resource (or partially if you would only send a subset of modified ones).

On Thu, 21 Feb 2019 at 12:00, Denis Arh notifications@github.com wrote:

I agree. But POST for rules endpoint is appending (or overriding existing rules)

— You are receiving this because your review was requested.

Reply to this email directly, view it on GitHub https://github.com/crusttech/crust/pull/46#issuecomment-465917187, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOPkO_kr0Phx79p4ubo0WDZS6lH2-q1ks5vPmA1gaJpZM4bGy49 .

[mitjaziv]

I agree. But POST for rules endpoint is appending (or overriding existing rules)

POST should be changed to PATCH.