This was printing arguments as their JSON serialized representation
rather than their text presentation.
It also couldn't handle missing arguments.
We also verified that writing the protection name wrong for the commands
will give you a message saying that the protection doesn't exist,
rather than showing the help command.
* 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 add the status command that was missing and show how other protections could add their own commands to Draupnir.
- We changed the token system to use a "lazy"[^lazy] version of leaky bucket, which isn't perfect but what was happening before was the protection counted the joins in the elapsed time, and then dropped them all rather than rolling over.
- We've given it a general tidy
The reason for this is because I want to use this protection to write generic documentation (a tutorial) on how to configure protections.
[^lazy]: "lazy" in the sense that we don't bother to remove tokens all the time, only when a token gets added, which is fine because the throughput on room joins will be tiny.
* Add command to change the active capability provider of a protection.
* Update MPS for persistent capability set config.
The command will actually persist the chosen capabilities
across startup.
Before the prompt would only show when there were rules matching the unbanned user. Now we only decide to hide the prompt when there are no rules and no room bans.
Fixes the unban propagation side of https://github.com/the-draupnir-project/Draupnir/issues/622.
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.
* Update matrix-appservice-bridge and use our own alias for matrix-bot-sdk
* Bump node version to support matrix-appservice-bridge
* Bump node version in CI
* Fix comments
* Add changelog entry
* 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.
* Initial attempt at this, but I don't like it.
We've managed to cnofuse rendering/command layer again just because
we started with the rendering rather than the command lol.
* Remove side effects from config renderers.
* Improve rendering of persistent configs in safe mode.
We should really also expand by default, and array properties in
details instead. Otherwise a new user might not expand by default and
might not know what's wrong.
* Remove <details> from configs themselves.
* Color blind indicators for config status.
* When config are bodged just render their reasons on the same line.
* Hide stack trace behind details.
* Update for MPS 1.6.0.
Specifically, when restart Draupnir fails, and safe mode is already
running, we will want to create a fresh safe mode instance that
contains the relevant recovery options, from the new cause of failure.
We need to look at Draupnir's .start method and make it `void`.
The report poller should just throw if it fails without being
caught by `Task`.
We also need to test the `toggle` in appservice in integration
tests.
Currently integration tests will be broken because we took control
over "who starts Draupnir?" away and gave it to the `SafeModeToggle`.
So we need to fix that.
gnuxie