-
Notifications
You must be signed in to change notification settings - Fork 52
Description
This stemmed from a conversation in element-hq/synapse#18908, and a corresponding Matrix conversation. The issue creator found that when using native MAS users and setting block_non_admin_invites: true
in their Synapse config, they still couldn't invite users despite being a Synapse admin. This was due to them trying to set the admin
flag in Synapse.
The user should instead have the can_request_admin
bit set on their MAS user, and then their Matrix client must request the urn:synapse:admin
scope. This is a very complex setup however, and means that some of the user's devices will be able to make invites, while others not.
In the matrix conversation, @sandhose concluded that the block_non_admin_invites
implementation in Synapse could instead check whether the user itself has the can_request_admin
bit, cutting out the intermediate work (and unifying behaviour across all a user's devices). The Synapse implementation (and likely other admin checks) could then be updated to check this instead.
Currently MAS does not communicate this information to Synapse. @sandhose mentioned that it could be made to do so, and sent over when a "provision user" job runs. This job could even be initiated when the can_request_admin
bit was toggled using MAS' admin API/cli.