Rocket.chat: Allow managing of roles and permissions via API

[mrsimpson]

Description:

Currently, managing roles and permissions is only possible via the admin-UI, there is no REST API for that.
However, particularly when administering multiple instances in a corporate environment, permissions need to be set consistently in order to meet corporate requirements

Server Setup Information:

• Version of Rocket.Chat Server: 0.58.1

[albanafmeti]

Is anybody working on this feature? Is this feature added in any last version of Rocket Chat?
This is a very important feature, especially for being part of API, so please do it.

@mrsimpson How do you manage this?

[mrsimpson]

@albanafmeti currently the worst way possible: manually.
Thinking about an exported Mongo-collection though

[ear-dev]

@kaiiiiiiiii Thanks for pointing this out.

@albanafmeti did you have any luck exporting these settings from mongodb collection?

I see this went into the backlog....... I'll monitor this issue in the hope that it moves forward.

Thanks!

[vynmera]

When doing this, it would probably be best to change our current Get Permissions route as well..
/api/v1/permissions -> /api/v1/permissions.list (breaking)
and a new /api/v1/permissions.update

How should the data be laid out? As it is in Mongo, or a different setup (e.g. listing every role, with every permission as a boolean field)? Do we keep the current meta fields?
As for the breaking route change, how do we handle it? Do we keep /api/v1/permissions and mark it deprecated?

I'd be up for implementing this, but I'll need some guidelines to work by :smirk:

[ear-dev]

@vynmera I think many would be grateful to have permissions implemented in the API!! That goes a long way toward automating and versioning configuration settings on a production RC server....

My opinion is that it would be ok to mark /api/v1/permissions as deprecated and to go with permissions.list, but maybe others have an opinion too.

I'm not sure what you're thinking when you ask about how the data should be laid out. I would think that the API would take /api/v1/permissions.update -d {"_id": "", "roles": ["role", "role", "role"]} thus reflecting the way the current list works.

[vynmera]

@ear-dev That is probably the best. I'm working on implementing this now. I'll make permissons.list practically the same as the current permissions, and add a permissions.update that will look somewhat like this:

{
    "permissions": [
        {
            "_id": "permission_one",
            "roles": ["user", "other_role"]
        },
        {
            "_id": "permission_two",
            "roles": ["admin"]
        }
    ]
}

This'll update permisson_one and _two to be granted to the roles listed, and keeps all other roles intact.
It'll return the same as permissons.list.

Is that OK? Also, do any project collaborators know how I should go ahead when deprecating an API endpoint?

[ear-dev]

@vynmera That looks good to me. My only question is about setting permissions in bulk, i.e. sending a list of permissions to be updated vs. just allowing one permission at a time per each call to permissions.update. Are there other examples in the API where one call will update many fields? It may be fine, it just complicates the payload structure. Maybe that's a non issue....

[vynmera]

@ear-dev One example would be users.update, I believe. I favor this sort of single-payload call, as it allows for far snappier actions and cost near to no extra overhead - in fact, I feel we should bundle all these channels.set* routes into a single channels.update...
But I'm up for suggestions.