This is actually really bad.
For multiple reasons.
The best way for this to be avoided is to drop everything
and reload it when the account data for watched lists is changed.
Then there isn't a situation where you have to inform anyone
about a change in what lists are being watched.
* Do not interrupt redact sequences due to error when backfilling
... Mainly timeouts.
* Change caught redaction error LogLevel from DEBUG to ERROR.
From matrix-org/mjolnir#479
---------
Co-authored-by: Marco Cirillo <marco.cirillo@aria-net.org>
Canonicalise the existence of the "admin room" for managing the appservice and Draupnir instances
* Add utilities for managing users in the admin room
* Merge the appservice admin room and access control list.
The majority of admins will need to use the draupnir admin commands
to manage the list.
* Utility methods for creating generic rules in PolicyLists.
* Commands for managing appservice users.
* Detail about important Draupnir concepts and context.
Stuff that is essential to understand if there's any hope of
maintaining this shit.
* Notes about the ban command.
* link to context in CONTRIBUTING.
* use matrix-appservice-bridge support for postgres
* upgrade matrix-appservice-bridge to include postgres fixes.
These are unreleased and a specific develop commit, but we're the only ones
who have made changes so far to the develop branch,
so should be fine.
* Upgrade matrix-appservice-bridge to 8.1.1.
8.0.1 was never added to npm for some weird reason.
TODO:
- Needs description adding into the detail rather than the summary
- needs rich text
- needs markdown detail/summary to not just be the HTML tags, unacceptable since it's supposed to be fallback
- More commands
Still neeed to do alias commands. I think that requires a dedicated
alias and resolved room type and room reference is some kind of union type
that can resolve to a concrete room id.
`details` and `summary` being put into html in markdown is unacceptable
regardless of whether popular implementations support it.
Plain text client will not lol.
What's being asked for is detail/summary on category of commands.
That can only really happen once Synapse admin commands are all grouped
together into one table.
* Experimental Protection to propagate room level bans to policies.
- Needs an automated option
- I really want this to be enabled by default
- It needs to be easily configurable and very visible because it's a really useful feature.
- Need to check that they are not already banned on a policy list.
- Allow possibility to rely last message like a report behind spoiler text.
* Use MatrixDataManager for enabled protections.
This will allow us to create "enabled by default" protections
via a schema migration.
* Enable BanPropagationProtection by default
* BanPropagation: only prompt when user is not already banned.
* Test for BanPropagationProtection.
* clearTimeout for prompt reactions if we got a reaction.
* Allow renderMatrixAndSend to not need a reply.
* document getFirstEventMatching
Gnuxie