- 04 Jan, 2017 1 commit
-
-
daryl herzmann authored
-
- 16 Dec, 2016 1 commit
-
-
Dave Cridland authored
This change means that room subject changes are no longer held within the history transcript, but instead are always sent in a distinct action afterward. Although this means that repeated changes will not be replayed in history, this seems to be normal behaviour on other servers, and simplified the history replay code considerably.
-
- 13 Dec, 2016 1 commit
-
-
Chinmay Dani authored
-
- 11 Nov, 2016 1 commit
-
-
姜为 authored
when canSendPrivateMessage is null will throw NullPointException if use canSendPrivateMessage() method when canSendPrivateMessage is null will return "anyone"
-
- 26 Jul, 2016 1 commit
-
-
Christian Schudt authored
This builds on / improves f2386cce, where affiliation updates were not broadcast correctly to MUC occupants. The error here is, when an owner/admin assigns the moderator role, the new role is not reflected in the presence broadcast. So neither the actor, nor all other particpants get notifications about the new moderator.
-
- 14 Jun, 2016 1 commit
-
-
Guus der Kinderen authored
-
- 01 Mar, 2016 2 commits
-
-
Christian Schudt authored
Also include the actor in every presence, not just the presence sent to the kicked occupant, so that other occupants know, who kicked whom. This is achieved by not creating a copy of the presence.
-
Christian Schudt authored
Previous stanza had status code 321 (membership revoked), but still had the owner and role set to the old role: affiliation="owner" role="moderator" Now it is the correct role after revoking membership: affiliation="none" role="none"
-
- 12 Feb, 2016 1 commit
-
-
Chinmay Dani authored
Removing registration from room calls #addNone, which removes the requester JID from all affiliation lists. But #applyAffiliationChange sets the affiliation back to 'member' after it does not find the JID in any affiliation lists. It should set the affiliation to 'none' before sending the updated presences.
-
- 09 Feb, 2016 1 commit
-
-
Derek McLean authored
When a room occupant sends an availability update to a host in an Openfire cluster, other users cannot join the room from other hosts in the cluster. The availability update causes the other hosts to lose an occupant's role and affiliation. New occupants encounter an NPE when joining and are prevented from joining the room. Specifically, the NPE occurs when Openfire attempts to send initial presences for current occupants. Remote hosts in the cluster lose the occupant's association because the local room simply broadcasts the presence packet for the occupant's availability update. Because it is from the client, this packet does not have the occupant's role or affiliation. The remote hosts treat the presence packet as the occupant's presence without modification. This fix changes the order in which Openfire handles an availability update. First, it updates its local view of an occupant's presence. This populates the correct association. Then, it broadcasts the updated presence to remote hosts in the cluster.
-
- 27 Jan, 2016 1 commit
-
-
wuchang authored
-
- 22 Jan, 2016 1 commit
-
-
Christian Schudt authored
-
- 12 Jan, 2016 2 commits
-
-
Ben Markwardt authored
After banning, the user is not kicked from the room. The user is added to the ban list so they can't re-join the room or post messages, but they are not kicked out of the room so the user can still receive messages sent to the room. The problem is an additional check for isMembersOnly() was only allowing users to be kicked from members only chat rooms. Whenever a user is marked as an outcast they should be kicked from the room regardless of if the room is a members only room or not. Looks like this problem was introduced in commit 822abb01
-
Ben Markwardt authored
Based on the MUC spec it should be sending "outcast" on banning. Looks like this was introduced in commit 822abb01
-
- 08 Jan, 2016 1 commit
-
-
Tom Evans authored
Returns the count of nicknames rather than the number of connections (full JIDs), which will now also match the list of occupants.
-
- 24 Dec, 2015 1 commit
-
-
Ivan A. Shmakov authored
add call of sendingInvitationRejection for MUCEventDelegate
-
- 07 Dec, 2015 1 commit
-
-
Tom Evans authored
Ensure that the MUC room subject is set correctly from initial request and upon subsequent reload.
-
- 27 Nov, 2015 1 commit
-
-
Dave Cridland authored
XEP-0045 discusses how a request to join a room is the only case where a MUC element should exist in presence. Therefore, a conformant client will always send this whenever it believes it is not joined. This can happen in cases of stanza loss (due to network outage) or remote server crash. This patch assumes that a client sending a MUC element is trying to join, and will go through much of the motions of the join, including sending history as required, existing occupants' presence, and so on. To other existing occupants, however, it'll look like an ordinary presence update.
-
- 09 Nov, 2015 2 commits
-
-
Christian Schudt authored
-
Christian Schudt authored
There were still ~1500 missing annotations! This time fixed with IntelliJ ;-)
-
- 13 Dec, 2014 1 commit
-
-
Christian Schudt authored
The problem here was, that the presence's 'to' attribute was overridden on each iteration, making the if statement fail after the first iteration.
-
- 13 Nov, 2014 1 commit
-
-
Tom Evans authored
Distribute updated presence packets after changing MUC room affiliations due to group membership changes
-
- 10 Nov, 2014 1 commit
-
-
Tom Evans authored
Introduces MUC group affiliation feature; allow users to join rooms based on group membership; distribute presence updates for MUC affiliation changes due to group membership events.
-
- 19 May, 2014 2 commits
-
-
Christian Schudt authored
-
Christian Schudt authored
-
- 06 May, 2014 2 commits
-
-
Christian Schudt authored
-
Christian Schudt authored
-
- 02 May, 2014 1 commit
-
-
zzglitch authored
-
- 11 Apr, 2014 1 commit
-
-
Tom Evans authored
Do not broadcast "unavailable" status for a nickname until last connection for the corresponding user leaves the room
-
- 10 Apr, 2014 1 commit
-
-
Tom Evans authored
Fixes a long-standing issue with Openfire's MUC implementation. See http://community.igniterealtime.org/thread/35355 for more information.
-
- 23 Mar, 2014 2 commits
-
-
csh authored
OF-760 MUC status codes 100, 201 and 210 should only be sent in self-presence and only in the context of entering a room git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13999 b35dd754-fafc-0310-a699-88a17e54d16e
-
csh authored
git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13998 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 05 Mar, 2014 1 commit
-
-
csh authored
git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13982 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 13 Feb, 2014 1 commit
-
-
Daryl Herzmann authored
git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13941 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 04 May, 2013 1 commit
-
-
Tom Evans authored
git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13637 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 03 May, 2013 1 commit
-
-
Tom Evans authored
git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13633 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 19 Apr, 2013 1 commit
-
-
Tom Evans authored
git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13616 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 23 Feb, 2013 1 commit
-
-
guus authored
OF-624: Added some defensive coding fragments (utilizing TINDER-68) that helps to prevent generating illegal JIDs. git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@13513 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 13 Feb, 2012 1 commit
-
-
guus authored
OF-523: Stop a NullPointerException from occuring when an attempt is made to kick an admin (which is not allowed). git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@12987 b35dd754-fafc-0310-a699-88a17e54d16e
-
- 12 Feb, 2012 1 commit
-
-
guus authored
OF-523: Apply defensive coding to the MUC implementation (mainly: use JIDs, not Strings - but includes some other fixes as well). git-svn-id: http://svn.igniterealtime.org/svn/repos/openfire/trunk@12978 b35dd754-fafc-0310-a699-88a17e54d16e
-