This allow a shell-command to provide a 'flags' field, which will automatically
cause the parameters to be fed through argparse.
The rationale is to make it easier for more complex commands to be invoked
from the command line (`prosodyctl shell foo bar ...`). Until now they were
limited to accepting a list of strings, and any complex argument processing
was non-standard and awkward to implement.
Secondary roles are an advanced feature without any strong use cases
currently. Having multiple ways to manage roles is confusing.
Now the 'user:role' command will just show the primary role if that is all
there is, but will list secondary roles too if there are any (which in 99.9%
of cases there won't be).
The array:pluck() method mutates the args, replacing the table items
with the resulting strings. On later runs I assume it tries to index the
string, which returns nil, emptying the array.
The field `_provided_by` comes from module:provides(), but these items
comes from moduel:add_item(), which include the originating module as a
'source' field of the event. However, this is absent when items are
retrieved at a later time than the initial event.
This allows us to continue sending/receiving on the session, for example if
the promise will be resolved by other data that the client is going to send.
Specifically, this allows the repl-request-input to work without a deadlock.
It does open the door to interleaved commands/results, which may not be a good
thing overall, but can be restricted separately if necessary (e.g. a flag on
the session).
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.
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.
