-
Notifications
You must be signed in to change notification settings - Fork 11.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't require user exist in a public room to add other users #5683
Comments
Actually, in the case where the user calling the method is an admin, would it be bad to allow adding users to private rooms too (where the admin is not a member)? I think I need that for the provisioning scenario. I can just do that on my fork without a PR though if it's not desired in core. |
I would say that a new permission |
Is this in 0.50.0 ? In my case I would like to add users to channels/private rooms without being in the channel. |
@maxdwit No it isn't, I will see about getting it into the next release though. |
@graywolf336 I was about to do this now, if you haven't yet? I'm going with your suggestion of adding a new permission, but for semantic accuracy I was thinking to change the original permission to be |
@timkinnane go for it. That sounds good to me, be sure to create a migration to rename the existing one if it's required. 👍 |
Yep, got it. ;) |
…mission-change Fix #5683, add add-user-to-any-room permission
Test in 0.51. via API, |
0.49.3
Question for core team, mostly @marceloschmidt - Is there a strong reason for requiring that a user calling
addUserToRoom
must be a member of the room.I have two uses cases I'm writing, 1st: automated workflows were a bot will drop people in a room at the end of an interaction. 2nd: provisioning scripts for new instances that will create rooms and add users according to a pre-defined config.
In both scenarios, I need the bot (1) and system admin (2) users to exist in the room first to add the new users - but they don't need to be there for any other reason and I don't really want users to see them in the room.
It makes sense for private rooms, but is there any good reason why I can't just remove that check for public rooms - there will still be the
add-user-to-room
permission check. I'm happy to make the PR if there's no objection to the concept.See relevant line.
The text was updated successfully, but these errors were encountered: