We were clearly in the process of deleting the
member decleration to just have the decleration be in the constructor.
When we were distracted, leaving a property named `readonly`, which
shouldn't be possible imo, need to add some rule for that prompto.
* .github/dependabot.yml: first attempt at grouping production & development dependencies
Resolves: #113
* dependabot: don't group production depedencies
* dependabot: group GitHub actions
Before CommandError's where and they are used
liberally for validating command arguments by
returning a CommandResult for several possible
options. Which gives a lot of spam. It's not necessary
anyways since these should only be used for known errors.
Shouldn't change what is being logged to the log file,
but it does change what gets sent to the management room.
I've been meaning to disable this for some time as it generally
confuses new users and it makes the bot feel very confusing and
low quality. It also means you are likely to miss more important
messages in the magement room.
Another problem it causes is an inconsistent view when testing
the software and it's an unreasonable burden to test for both
settings.
It's not clear what the value of this setting is apart from
providing comfort to some users who want to see the ACL readout.
But even then it's a very inefficient way of doing that,
so i'd rather another feature be requested by users that want to see that.
Sometimes we don't need exceptions to be reported on the error level.
This is especially true when the user does something out of order
and there's a permission error.
If we're aware of that possibility as developers and have accounted
for it, then it's unnecessary for it to be treated the same way
as a fatal error.
We also decided to log CommandExceptions and CommandErrors as
early as possible.
https://github.com/Gnuxie/Draupnir/pull/93/
We've done this to make the implementation a lot cleaner and
managable. However, we've taken the opportunity to simplify
all of the client code that would use this method.
Some of these simplifications might come at a small cost.
Updating server ACL, member bans and checking power levels
would all be clearly titled as seperate checks.
However, it should still be obvious what has gone wrong,
since any error would have to give a more detailed explanation.
And not everything is going to fail all at once (and if it does,
there are bigger issues).
a lot cleaner
https://github.com/Gnuxie/Draupnir/pull/85
A bizarre contraption.
The ErrorCache was seemingly introduced to reduce the number of errors
in the management room.
https://github.com/matrix-org/mjolnir/commit/82214c6cd88d83abed05fec4a871a874e6e0265b
It makes sense why it was added if you consider that many admins
will run Draupnir without giving it the permission to manage server
ACL in its rooms. Though, I'm not sure why then you would add the error
cache rather than properly supporting that use case.
So perhaps there were other reasons.
Either way, what is drawing the line for me is that the ErrorCache
will suppress any error within rooms that is not a permission error,
if there was any error that was not a permission error within a
15 minute window.
Considering the typical Draupnir will not even sync
for hours at a time, even in large communities.
It does present a problem for rooms with a lot of join/leave events.
I think that's probably why the error cache was added.
Ahh, well, fuck.
Well what is the real solution to this?
The real solution when the kind is acl is to allow the bot to run
without applying ACLs.
Ok fine but, hey wait a minute.
Why would there be any other kind of persistent error
when banning someone that would be unimportant enough to silently
hide in an ErrorCache??
IDK let's just add an opttion to disable server ACL,
since they might want to use another tool for that anyhow.
Out of scope for the current work though.
https://github.com/Gnuxie/Draupnir/pull/85
This adds the `displayname` command which just sets the displayname of the user.
-----
* Add command that allows to easily set the Displayname of a bot
* Only set the displayname once
* Add missing matrix interface adaptor and use CommandError
* Make displaynames with spaces work
This adds a `/healthz` endpoint to the appservice which allows this to work more nicely in kubernetes.
It also adds some metrics for tracking the provisioning state.
Grafana result:
Note: The ts-ignore are sadly required since the `_getValue` method is not public :/ I didnt find another solution apart from tracking it maybe elsewhere.
* Add health endpoint to appservice and add metrics via prometheus
* Ensure that we dont have duplicate metrics when the appservice is registered multiple times
* Move gauge modifications to utils function
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix typo
* Use the new help style on the appservice commands and add missing descriptions for the arguments
* Make the first letter of the table name uppercase in the help table
MTRNord