This should simplify adding shell commands from other modules, which will
reduce the growth of mod_admin_shell and make it easier for community modules
to expose commands too.
Some of the new roles don't quite fit nicely into 4 characters
(excluding ellipsis). Given the ability to dynamically add additional
roles from the config and possibly from modules, it seems better to just
make it a relative size since we can't know how long they will be.
When mod_admin_socket is loaded without mod_admin_shell, attempt to use
`prosodyctl shell` will appear to freeze after any input, since no
response is returned.
user:roles() does not convey that this is the mutating command, it
should have been called setroles from the start but wasn't due to lack
of foresight. This has to accidentally removing roles when wanting to
show them.
Due to the dummy statistics provider (see core.statsmanager line 250)
having a metatable that allows infinite indexing where everything is
always the same table, which end up in suf() in the concatenation line.
This gives us more granular control over different types of user account.
Accounts registered by IBR get assigned prosody:registered by default, while
accounts provisioned by an admin (e.g. via prosodyctl shell) will receive
prosody:member by default.
Removes some dead code and hopefully simplifies a bit.
There's a tree of possibilities with the two tri-state status
properties, something like
chain:
* nil -- cert validation disabled?
* invalid -- something wrong with the chain (including ee cert)
* valid -- chain ok
cert:
* nil -- incomplete validation??
* invalid -- mismatched names or such
* valid -- all good!
We had config:get() but not this.
> <MattJ> Yeah, why did we never implement that?
Handy if you want to quickly try out settings without reloading the
whole config.
Since prosodyctl shell with additional arguments assumes the first two
are a section:command() and any following arguments are strings, passing
a bare 'nil' is not possible. In order to avoid delving into this rabbit
hole, instead produce a token that alone is not really a legal JID for
use as wildcard.
Idea here is to prevent a user from being created with the default role
if a different role was given, but that dance wouldn't be needed if no
role is provided.
E.g. module:info("http") with many http modules loaded would show a lot
of duplication, as each module would be listed for each host, even if
not actually enabled on that host.
Matthew Wild