Previously, anyone (even across federation) could invite you to a
room and the bot would join. It may not have provided a useful purpose,
but it still joined all rooms it was invited to.
We now only join rooms when we're invited by a person who is actually
allowed to use the bot.
Fixes https://gitlab.com/etke.cc/postmoogle/-/issues/17
Fixes:
> `mailbox` of this room set to `test@domain@domain`
Previously fixed in 97a4d6c7bc, but it seems like we unintentionally
reintroduced this bug again at some point after that.
When someone first joins a room, they see some commands (`mailbox`,
`owner`, ..) and they know they are getters and setters, but they have
no good example as to how to use them.
Is it `!pm mailbox SOMETHING` or `!pm mailbox=SOMETHING` or something
else?
It's better if the introduction text gives you the full command you need
to get started (e.g. `!pm mailbox SOME_MAILBOX`), instead of a partial
command that you don't know how to use (e.g. `!pm mailbox` - this is
merely a getter and will not set your mailbox to `SOME_MAILBOX`).
Starting from this, I thought it would be a good idea to make all
option getters tell you how the commands are to be used. If you send
`!pm mailbox` and it tells you "not yet set", it should also tell you
how to actually set it (e.g. `!pm mailbox VALUE`).
If're an admin and mess up the `users` list, you won't see "owner"
commands.
If you're just a regular room user (not an admin, not an owner), you'll
only see the `help` command in the `help` message.
Both of these situations may make you wonder:
- is that all there is?
- earlier I saw more commands, so what's going on?
Adding "and accessible to you" hopefully clears things up, or at least
it tries to make the help message more correct.
Now that we use Match() in allowAdmin() as well, it's awkward to
have it return `true` when called with an empty admin list.
No admins defined was taken to mean "everyone is an admin".
We can either have a `len(users) == 0` check in `allowAdmin` which
rejects the request, or we can change `Match()` so that it doesn't
return positive responses when called with an empty list. Doing the
latter sounds better. It's more natural that matching against an empty list
will yield "no match".
This can be improved in the future, to show some additional information
about each mailbox like:
- "how many users are in that room"
- "which users are in that room"
- "who is the owner of the mailbox"
This can all be done later though.
Checking using `settings.Allowed` is odd. Not all commands are related
to setting configuration settings. Admin commands are coming in the
future, for which this is certainly not the case.
We now do access checks early on (during command processing), so command
handlers can be clean of access checks. If we're inside of a command
handler, the user is privileged to run it.
Aine
Aine
Slavi Pantaleev