- Send a warning message when the event gets removed.
- Ban on the second infraction.
- Make it an option as to whether the message gets split.
- The config file won't work anymore can't fix that because wuh we can't have both as the source of truth........ unless we differentiate based on the timestamp but that requires infrastructure changes.
And also do purging deactivation in the background
We introduce "restriction" as a way to refer to an account that has
been suspended or locked or shadowbanned etc.
We also add a UserRestrictionCapability for protections to use the
functionality for suspending users.
We keep an audit log that updates when missing account restrictions
are discovered. (IE those that are prexisting)
The protection that makes these features available is the
HomeserverUserPolicyProtection.
- The _Redaction Synchronisation Protection_ has been improved in a few ways:
- Invitations in protected rooms will be rejected as part of the redaction
process when they are sent from users being redacted (e.g. as a brigading
tactic).
- User redaction will now be triggered on bans and the reason will be scanned
for `automaticallyRedactForReasons` from Draupnir's config.
* Update RedactionSynchronisation for new protection apis.
* Rerwrite redaction synchronisation protection
* Reject invitations on ban.
* Add renderer and simulated redaction synchornisation capability.
* Reduce dependencies of redaction synchronisation protection.
* Allow RedactionSynchronisation to be unit tested.
* Update to MPS 3.1.0.
---------
Signed-off-by: Rory& <root@rory.gay>
Co-authored-by: Rory& <root@rory.gay>
We introduced a new PolicyRuleChangeType enum with a variant for
revealed literals. And we changed our mind about where reversal will
happen, it'll happen in the room state manager factory.
We need to do this because they will be impossible to obtain once the
room has been blocked on the server.
We also need to make sure we now include the server the room was
created on, and the creator in the room hash store.
We no longer want to accept an argument for the list. We will just
find all appropriate policies and remove them, like we do with the
unban prompt (which we still might want to update to use the new
`--no-confirm` prompt later).
We fix the bugs where the unban command was inviting users regardless
of whether the `--invite` option was provided.
The unban command now uses a preview which shows all the policies that
will have to be removed to unban a user, all the rooms they will need
to be unbanned from, and any rooms that they will be invited to if the
`--invite` option is used.
This simplifies anything to do with the way policy rooms are watched.
There was a lot of weird glue code around finding policy rooms and
revisions that has just been whipped out into the WatchedPolicyRooms
abstraction.
This function now distinguishes between lists we are watching, lists
that are protected, and lists that we have parted from.
I don't like it. This should exist on the `PolicyRoomsManager` and
this is a complete and total mess. I don't know if there is time to
fix it yet.
This PR closes#622 by adding a `--invite` flag to the `unban` command.
* Add --invite to `unban` command (untested)
* Use RoomInviter to invite users in unban command.
* Condense unban(+invite) log message
---------
Signed-off-by: nexy7574 <git@nexy7574.co.uk>
Co-authored-by: gnuxie <Gnuxie@protonmail.com>
* Test UnbanCommand and UnbanPrompt have unbanned as a side effect.
You'd think it would be obvious, but clearly it hasn't been. Part of
the reason for it is just how un-ergonomic it used to be to verify
room state. Fortunately it's quite straight forward to do since MPS
has picked up. So now we can do it easily.
* Update for MPS 2.5.2.
- Fix SchemedMatrixData putting the wrong version number into data.
Sadly a complication of
https://github.com/the-draupnir-project/Draupnir/issues/560.
- Fix an issue where the implementation of the RoomUnbanner capability
was actually calling `/ban`.
* Stop using `setSerializedValue` on protection settings.
We don't need it now that we've updated the command reader.
* Update interface-manager and MPS.
* Enable standard presentation type translators.
This will fix issues with the ban command reason.
We introduce a new interface `ManagementRoomDetail`, and our implementation of this has immediate access to the room members and room state.
Immediately, this allows us to warn when the management room is public.
In the future, it gives us a nice place to decide things like decide whether membership of the management room is enough to be considered a moderator, introduce more redundancy in access control, and give capabilities a way to determine who is a moderator (and avoid enacting consequences against them).
* Move management room to its own folder so we can start introspecting on it.
* Add ManagementRoomDetail.ts
This is just used to track who is a moderator and whether the
management room is public.
* Update ManagementRoomOutput to depend on ManagementRoomDetail.
This should allow us to implement the feature that warns when
the management room is public.
* Send a warning if the management room is public.
Fixes https://github.com/the-draupnir-project/Draupnir/issues/413.
* Update to MPS 1.7.0 so we can get the join rule event.
* Rename read to configRead as it should have always been.
* Got a way to extract non-default values.
Now let's try unknown configuration values.
* Show unknown property paths with a warning.
Now we just need to make this scrap available in commands.
* Remove the old Mjolnir horrible RUNTIME client.
* Make the path that is used to load the config available.
* Warn when `--draupnir-config` isn't used.
* Introduce configMeta so that we can log meta on process.exit later.
* Only show non-default config values when draupnir is exiting.
to reduce noise.
* Get consistent with logging.
So it turns out that mps4bot-sdk is using a different instance
of the bot-sdk module than Draupnir, i think.
Since we used to tell MPS's logger to use the bot-sdk's `LogService`,
but the `setLogger` that was used was obviously inconsistent with
Draupnir's.
Obviously the bot-sdk should be a peer dependency in the bot-sdk
to prevent this happening in future.
* Update to MPS v1.2.1.
This will allow us to use `describeProtectedRoomsSet` in unit tests.
* Update to @the-draupnir-project/interface-manager@1.1.1.
This allows for better type inference from the command and also for
partial keywords to be provided to commands as arguments.
* Unit test the DraupnirKickCommand.