Fix D4A Documentation flaw
In the process of writing the Draupnir for all role documentation it was forgotten that Draupnir needs to have the ability to write to the main management room policy list that controls who can access the bot. This flaw was overlooked during development as naturally without thinking the bot had these powers. Upstream Docs had this exact bug also and the author of this commit will have to go and fix upstream docs also to resolve this bug.
This commit is contained in:
parent
63dc5322f4
commit
c1cc5e1595
@ -67,6 +67,8 @@ The installation of Draupnir for all in this playbook is very much Alpha quality
|
||||
|
||||
Draupnir for all includes several security measures like that it only allows users that are on its allow list to ask for a bot. To add a user to this list we have 2 primary options. Using the chat to tell Draupnir to do this for us or if you want to automatically do it by sending `m.policy.rule.user` events that target the subject you want to allow provisioning for with the `org.matrix.mjolnir.allow` recomendation. Using the chat is recomended.
|
||||
|
||||
The bot requires a powerlevel of 50 in the management room to control who is allowed to use the bot. The bot does currently not say anything if this is true or false. (This is considered a bug and is documented in issue [#297](https://github.com/the-draupnir-project/Draupnir/issues/297))
|
||||
|
||||
To allow users or whole homeservers you type /plain @draupnir-main:matrix-homeserver-domain allow `target` and target can be either a MXID or a wildcard like `@*:example.com` to allow all users on example.com to register. We use /plain to force the client to not attempt to mess with this command as it can break Wildcard commands especially.
|
||||
|
||||
### 2. How to provision a D4A once you are allowed to.
|
||||
|
Loading…
Reference in New Issue
Block a user