Only list-multi and list-single fields require at least one value when
submitting a form. In other cases, for example XEP-0045's
muc#roomconfig_roomadmins, which is of type jid-multi, is used without
any values to reset the room's admins list.
Fixes SMACK-946.
When an occupant gets its membership revoked in an members-only room, the appropriate method of registered ParticipantStatusListeners should be invoked.
After test execution, the OpenPGP for XMPP integration tests should clean up the data published via PEP. This prevents these tests from interfering with other tests.
Additional cleanup of test fixtures:
- various tests that change roster/subscription get a roster-reset
- one test that registers a listener now deregisters that listener
The test that's modified in this commit asserts that upon MUC join, stanzas are received in a particular order.
The previous implementation depended on several event listeners (one for presence, one for messages) that did not always fire in the same order in which the corresponding stanzas arrived. This made the approach unsuitable to reliably test the order in which stanzas arrive.
This commit stops using Smack's MUC API when trying to collect the order in which stanzas arrive. Instead, it joins a chatroom and listens for its stanzas using basic stanza handling. As this uses exactly one stanza listener, that's guaranteed to be invoked in order of stanza arrival, any synchronicity issue in the previous implementation no longer applies.
XEP-0115 defines that any dataforms in the disco#info stanza is
ordered prior to the computation of the verification string. This
commit adds a test that verifies that this is done by Smack.
See SMACK-944.
MUC mediated invitations usually have the form
<message
from='coven@chat.shakespeare.lit'
id='nzd143v8'
to='hecate@shakespeare.lit'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite from='crone1@shakespeare.lit/desktop'>
<reason>
Hey Hecate, this is the place for all good witches!
</reason>
</invite>
<password>cauldronburn</password>
</x>
</message>
(source: XEP-0045 Example 57.)
However, previous versions of XEP-0045 specified an additional <x
xmlns='jabber❌conference'> element to be included (see
implementation note in XEP-0045). Therefore, a legacy implementation
may emit a mediated invitations in the form of
<message
from="smack-inttest-mediated-invite-from-8ta77-hw9igz@conference.example.org"
to="smack-inttest-two-8ta77@example.org">
<x xmlns="http://jabber.org/protocol/muc#user">
<invite from="smack-inttest-one-8ta77@example.org"/>
</x>
<x xmlns="jabber❌conference" jid="smack-inttest-mediated-invite-from-8ta77-hw9igz@conference.example.org"/>
</message>
Unfortunately, this matches
MultiUserChatManager.DIRECT_INVITATION_FILTER because
GroupChatInvitation matches <x xmlns="jabber❌conference"/>. However
the message is not a direct invitation but a mediated one. Besides
this invoking the wrong listeners (direct vs. medidated) the value for
'inviter' that's used to invoke that listener will be false.
To fix this, extend DIRECT_INVITATION_FILTER with
NotFilter.of(MUCUser.class) to avoid matching those legacy mediated
invitations.
Fixes SMACK-943
Co-authored-by: Florian Schmaus <flo@geekplace.eu>
Making use of the new assertion handling for MultiResultSyncPoint, the integration test that uses that implementation can now get improved assertion messages. This will allow users to more quickly determine why a test is failing.
When occupant One waits for occupant Two to join the room, One should register the corresponding listener _before_ Two joins.
Without this, a race conditions occurs, where Two could have joined the room before One registered the listener, thus missing the event.
The test was originally implemented when version 1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.3.0.
The test was originally implemented after the most current version of the XEP was published, making it plausible that this implementation matches the current version of the XEP: 0.3.
The test was originally implemented when version 1.15.7 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications (with regards to the functionality that is the subject of the tests), making it plausible that this implementation matches the current version of the XEP: 1.26.0.
The test was originally implemented when version 2.0 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 2.0.1.
The test was originally implemented when version 0.1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 0.2.0.
These tests were originally implemented when versions 0.2.1 and 0.3.0 of the XEP were the most current version. Later versions of the XEP do significantly modify the specifications, making it plausible that this implementation matches the version of the XEP that was the most recent version at the time the test was created: 0.3.0
The test was originally implemented when version 1.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.2.
The test was originally implemented when version 1.25 of the XEP was the most current version. Later versions of the XEP do significantly modify the specifications, but the test implementation has had continuous changes over time too. This makes it plausible that this implementation matches the current version of the XEP: 1.34.6.
