1. 04 Jan, 2017 1 commit
  2. 16 Dec, 2016 1 commit
    • Dave Cridland's avatar
      OF-1061 Always send room subject after history (#702) · 6c67e99e
      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.
      6c67e99e
  3. 13 Dec, 2016 1 commit
  4. 11 Nov, 2016 1 commit
  5. 26 Jul, 2016 1 commit
    • Christian Schudt's avatar
      Update presence after setting a MUC role or affiliation. · 3b10faa3
      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.
      3b10faa3
  6. 14 Jun, 2016 1 commit
  7. 01 Mar, 2016 2 commits
  8. 12 Feb, 2016 1 commit
    • Chinmay Dani's avatar
      Set affiliation to 'none' after removing registration from room. · 291af23c
      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.
      291af23c
  9. 09 Feb, 2016 1 commit
    • Derek McLean's avatar
      Cannot join room in a cluster after an availability update. · 1a5781c9
      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.
      1a5781c9
  10. 27 Jan, 2016 1 commit
  11. 22 Jan, 2016 1 commit
  12. 12 Jan, 2016 2 commits
    • Ben Markwardt's avatar
      User not kicked from room after banning. · f48d8989
      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
      f48d8989
    • Ben Markwardt's avatar
      Openfire sends presence updates of affiliation "none" instead of "outcast" when banning. · 6ddb7424
      Ben Markwardt authored
      Based on the MUC spec it should be sending "outcast" on banning.
      
      Looks like this was introduced in commit 822abb01
      6ddb7424
  13. 08 Jan, 2016 1 commit
    • Tom Evans's avatar
      OF-821: Count occupants by nickname · e9e1000e
      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.
      e9e1000e
  14. 24 Dec, 2015 1 commit
  15. 07 Dec, 2015 1 commit
  16. 27 Nov, 2015 1 commit
    • Dave Cridland's avatar
      Assume a client with MUC elements in presence needs to join · b853644c
      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.
      b853644c
  17. 09 Nov, 2015 2 commits
  18. 13 Dec, 2014 1 commit
  19. 13 Nov, 2014 1 commit
  20. 10 Nov, 2014 1 commit
  21. 19 May, 2014 2 commits
  22. 06 May, 2014 2 commits
  23. 02 May, 2014 1 commit
  24. 11 Apr, 2014 1 commit
  25. 10 Apr, 2014 1 commit
  26. 23 Mar, 2014 2 commits
  27. 05 Mar, 2014 1 commit
  28. 13 Feb, 2014 1 commit
  29. 04 May, 2013 1 commit
  30. 03 May, 2013 1 commit
  31. 19 Apr, 2013 1 commit
  32. 23 Feb, 2013 1 commit
  33. 13 Feb, 2012 1 commit
  34. 12 Feb, 2012 1 commit