| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| | |
Missed the # in 93c1590b5951
|
| | |
| |
| |
| |
| |
| | |
I forget why I wanted this, but it may allow doing things like pull
settings from the column, especially when the mapper function is reused
among many columns.
|
| | |
| |
| |
| |
| |
| | |
As an alternative to doing it in the mapper function. Could be useful in
cases where one may want to put the ellipsis in the middle or beginning
instead of the start.
|
| | |
| |
| |
| |
| | |
In order to allow it to adjust its output to available space, apply its
own ellipsis method or other compacting method.
|
| | |
| |
| |
| | |
Reasoning: a hostname is one part, a JID is 3 parts.
|
| | | |
|
| | |
| |
| |
| |
| | |
Harder to accidentally count wrong if Lua is doing the counting on a
plausible input.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Makes it easier to make out where the set starts and ends in cases where
it may get embedded and tostring()-ed in a log message.
{ } taken over from util.array for consistency with some other systems
syntax for Sets, e.g. Python
|
| | |
| |
| |
| |
| |
| |
| | |
Arrays in Lua do use { } but since __tostring is often user-facing it
seems sensible to use [ ] instead for consistency with many other
systems; as well as to allow the {a,b,c} formatting to be used by
util.set without being confused with util.array.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Instead of a percentage, this allows you to specify e.g. `width="[N]p"`, where
a width="2p" will be twice the width of a width="1p" column.
Compatibility with the old %-based widths is preserved, and percentages adding
up to more than 100 are handled more gracefully.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
For some unknown reason, this was required with the old mock util.time
functions prior to 012d6e7b723a.
After 012d6e7b723a, it breaks. So I'm happy to revert to not delaying
anything. This makes tests pass again.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With monotonic() frozen, timers may fail to trigger. This caused problems
after the new util.startup changes that moved the server-started event to a
timer. The timer wouldn't trigger, the event didn't fire, and prosody would
fail to daemonize.
All the tests that depend on specific time behaviour are depending on wall
clock time, so only mocking util.time.now() and os.time() fixes those.
|
| | |
| |
| |
| |
| |
| | |
This method ends up going up for each collection and the :clear() method
is only available to global modules (see e.g. mod_c2s), while regular
per-host modules get scoped stats
|
| | |
| |
| |
| |
| | |
Motivation: Investigating clients that seem to forget to set CSI.
Also, of course, MORE GRAPHS!
|
| | |
| |
| |
| | |
We probably want to refactor revoke_token() to use this one in the future.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
There shouldn't be one here but if there is, for some reason, it's
better to close it than have it around to wake up and possibly try to
destroy the session.
|
| | |
| |
| |
| |
| |
| | |
Unsure exactly how this happens, but sometimes a watchdog appears to
close a session that isn't hibernating, or hasn't hibernating long
enough.
|
| | |
| |
| |
| | |
Other places doesn't have "mod_" there, why should it here?
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This is a convenience function, and there is currently no module-specific code
required to implement it. Not using 'self' is to be expected.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is a common pattern for modules to do something like check for
prosody.start_time, and execute code immediately if it is present, or wait for
the server-started event if it isn't yet. For example, this allows you to run
code after all other modules/hosts have been loaded, that are going to be
loaded.
Such code can now be replaced with a simple call to this method.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
To avoid a race where server-started fires before the promise function body is
run (on next tick), I moved server-started to fire on the next tick, which
seems sensible anyway.
Errors are logged, I'm not sure if we ought to be doing something more here.
I'm sure we'll find out.
|
| | |
| |
| |
| |
| | |
Only supporting exact match on full JID isn't helpful if you want to
list sessions per host or user.
|
| | |
| |
| |
| | |
For mod_invites_register to apply on user creation.
|
| | |
| |
| |
| |
| |
| | |
Part of an update to mod_invites and friends to the new authz and roles.
Invites with roles in the old way will need to be migrated, but with
invites often being short lived it is probably not a long-lived problem.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
By checking the password_updated_at for non-nilness before using it,
we avoid a nasty crash :-).
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This is another iteration on top of the previous sub-tokens work. Essentially,
the concept of a "parent token" has been replaced with the concept of a
"grant" to which all tokens now belong. The grant does not have any tokens
when first created, but the create_token() call can add them.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Properties of sub-tokens:
- They share the same id as their parent token
- Sub-tokens may not have their own sub-tokens (but may have sibling tokens)
- They always have the same or shorter lifetime compared to their parent token
- Revoking a parent token revokes all sub-tokens
- Sub-tokens always have the same JID as the parent token
- They do not have their own 'accessed' property - accessing a sub-token
updates the parent token's accessed time
Although this is a generic API, it is designed to at least fill the needs of
OAuth2 refresh + access tokens (where the parent token is the refresh token
and the sub-tokens are access tokens).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current method logs scary "access denied" messages on failure - this is
generally very useful when debugging access control stuff, but in some cases
the call is simply a check to see if someone *could* perform an action, even
if they haven't requested it yet. One example is determining whether to show
the user as an admin in disco.
The 'peek' parameter, if true, will suppress such logging.
The :could() method is just a simple helper that can make the calling code a
bit more readable (suggested by Zash).
|
| | |
| |
| |
| |
| |
| |
| | |
We expect every session to explicitly have a role assigned. Falling back to
any kind of "default" role (even the user's default role) in the absence of
an explicit role could open up the possibility of accidental privilege
escalation.
|
| | |
| |
| |
| | |
Spaces, no hyphen, apparently.
|
| | |
| |
| |
| |
| | |
Fixes that otherwise the user was created in a disabled state and left
as such.
|
