| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously the error messages said that it failed to "publish" to PEP, but
sometimes a sync involves removing items, which can be confusing.
The log was also the same for both legacy PEP and private XML bookmarks.
Having different log messages makes it easier to debug the cause and location
of any sync errors.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It appears that when:
1) The user has no bookmarks 2 node in PEP
2) The client publishes an empty bookmark set to a legacy bookmarks location
3) mod_bookmarks will attempt to purge items from the non-existent node and
log an error about the failure (item-not-found).
This new code will suppress an item-not-found error from the purge operation
in the empty-bookmarks case, and adds a log message for any other error (this
is helpful because the existing log message confusingly says it was an error
*publishing* to the node, which isn't always accurate).
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
