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).
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 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.
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.
Matthew Wild