Rocket.chat: API calls for groups/private channels does not work for admins

[cchbr]

Description:

When trying to get information on a group through the API as an administrator, I always receive the following response:

{
"success": false,
"error": "The required \"roomId\" or \"roomName\" param provided does not match any group [error-room-not-found]",
"errorType": "error-room-not-found"
}

This is probably due to the fact that the admin is not a member of the group, but in my opinion the admin should be able to see all channel and not have to join the private channels.

Steps to reproduce:

1. Authenticate as an administrator user.
2. Call any API endpoint for a specific group such as; groups.members, groups.info, groups.history.

Expected behavior:

The API calls should work because the administrator should have access to all channels.

Server Setup Information:

• Version of Rocket.Chat Server: 1.2.1
• Operating System: Ubuntu
• Deployment Method: Docker

[MarcosSpessatto]

Hi @cchbr, Yes you are right, this error occurs probably because the user is not part of the private group. Actually only members of the private groups can fetch data.

[gourav-kandoria]

Hi @MarcosSpessatto , Shouldn't the api be such that if the calling user is admin than irrespective of wheather he/she is part of group or not, they should be able to get the group info. since, there is also an api group.ListAll which provide you info of all groups. So, why not have an handy api for admins through which they can retrieve info of a particular group?

[sistason]

I'd very much like this features, as I'd like to crawl my Rocket.Chat instance for group-members and sync them / do other stuff with them.
I'd now have to create a sync-admin user adding itself to all private groups to implement getting a member-list of who is in which group, information which should be available to an admin user.
Use cases are to sync team memberships to private groups, for which getting the current member-list should be done first.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[amottier]

I agree with @gourav-kandoria : when calling an API using an admin account I would not expect to get an answer not-allowed.

[yalanyali]

I agree. It doesn't make sense that an admin is not allowed to call certain API endpoints. In an integration scenario you could want the users to be able to create but not delete private groups and delete them through the app backend as THE admin. With the current design we don't really have an "admin" account that we can use on a backend so that everything is done through the backend.

The admin cannot delete a private group without being a group member but it is possible for the admin to get the group owner's ID, create a token for the owner user and call the API as the user. I'd say just bypass the need for the owner's authorization at this point.

We need an admin account with full permissions for certain use cases.

It would also make the API documentation A LOT easier to comprehend. The explanation for the "Group Delete" endpoint is "Remove a private channel." Well, yeah... Unless you're not a member, then you'll get error-room-not-found and try to figure out why.

You want to invite a member to a private group as the admin without being a member yourself? Sure, just make sure you have the correct permissions set. Oh you want to get the group info right after? Well sorry, it is private, duh?!

The current design makes it very hard to maintain the API documentation and the permission system, as we can see. If I create an admin account, I expect the account to have full permission, I don't want to go and hope to see that there's a permission for the thing I want my backend server to do. I want to be able to do anything on my backend server. I have full database access there anyway. If you think it is a niche use case or a security problem, just let me have ADMIN_IS_AN_ADMIN environment variable. I don't think it would further complicate things from the user standpoint to have a _real_ admin role. This is a systems problem, not a user problem. Remember, APIs are there for us to build systems so that computers can communicate. I'm sure they'll behave.