| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is happens if the account is new and doesn't have any bookmarks
yet, which is not a problem.
Rarely seen since most clients currently use the older version of
XEP-0084 stored in XEP-0049 rather than in PEP, but at least one
(Converse.js )does.
One scenario in which this would show up often is with Converse.js as a
guest chat using anonymous authentication, where all "accounts" would
always be new and not have any bookmarks. This scenario probably does
not need to have mod_bookmarks at all, but if enabled globally it would
likely become loaded onto the VirtualHost unless explicitly disabled.
|
| | |
|
| |
|
|
|
|
|
|
| |
Found by accidentally publishing {urn:xmpp:bookmarks:0}conference
instead of :1 due to testing this earlier for the blocking.
By the principle of garbage in, garbage out, just generate a bookmark
from the item id / JID and carry on with a warning.
|
| |
|
|
|
|
|
|
| |
Having both the :0 and :1 nodes would be especially awkward, since there
is no upgrade path for this case. In theory, these should be rare since
no clients should have been doing XEP-0402 unless mod_bookmarks(2) was
enabled. This was guesstimated to be rare with most clients doing
XEP-0048 with Private XML.
|
| |
|
|
| |
Should save some cycles and not log the debug message on every login.
|
| | |
|
| |
|
|
| |
For compatibility with clients relying on the notifications
|
| |
|
|
|
| |
Might be nice to reduce amount of things happening on connect once
all users has upgraded
|
| |
|
|
| |
See 1dc00ca6ee9d
|
| | |
|
| | |
|
| |
|
