In the previous commit, the mock connection object was refactored to use a real
Strophe.Connection object.
This caused a test in spec/controlbox.js to fail (due to a method that was now
no longer mocked).
Added a quick workaround (via monkeypatch) for now.
onChatRoomPresence and showStatusMessages have been refactored to give more
detailed information and to also show the reasons given to actions taken by
moderators.
* Filter by both fullname and jid when searching for users to invite.
* Combine the confirm and prompt popups into a single confirm popup.
* Bugfix in groups filter. Make sure to show group that were previously filtered out.
The RosterView view is now an overview of RosterGroup objects.
RosterGroup objects each have their own collection of contacts which fall under that group.
Additionally, the RosterView has a collection of all contacts.
The comparator of RosterContacts is now used to correctly position roster
contacts and we therefore no longer need to explicitly sort them afterwards.
updates #83
updates #151
This is because we can no longer assume a one to one mapping between roster
contacts and their views. Roster contacts can belong to more than one group,
each group needs to show the contact, which means we need a view for each group
the contact belongs to.
updates #83
In order to make group values non-distinct, (i.e. buddies can be in multiple
groups), we can't assume there's one view per roster item.
This means we cannot manage the rosterview as an overview (since it makes this
assumption).
* Differentiate between adding new roster items and rendering existing ones.
* Also, only sort pending and requesting contacts once they've all been added
(similar to what was already being done with existing contacts)
Instead of differentiating between trimmed chats and minimized chats, the two
are now combined into the same thing.
This commit contains some initial work, but functionality is still impaired.
Some of the tests were failing because they didn't expect the controlbox to be
returned from localStorage.
It's too long ago that I've looked at this branch for me to say whether this is
a legitimate bug or not.
Will have to investigate further.
- use the same method for both normal and OTR messages
- fix /me actions for OTR messages
- rename messaging methods to minimize ambiguity
Conflicts:
converse.js
tests/utils.js
Did more investigation with regards to subscription requests.
As far as I can tell, roster updates will only show ask='request' for 'pending
out' requests.
For 'pending in' requests (what converse.js calls requesting contacts), roster
updates are not used and instead a presence stanza with type 'subscribe' is
used.
This makes sense. When sending a presence with type 'subscribe', we need a way
to keep track of our outgoing subscriptions. The XMPP server helps us do this by
adding a user to our roster with ask='request' and subscription='none'.
When our contact receives our presence with type 'subscribe', they have the
information they need. If they go offline and online again, the XMPP server
will resend the presence with type 'subscribe'. So a roster item is not needed.
In convere.js's internal representation of the roster (via the RosterItems backbone
object) we need to add roster items for 'pending in' contacts so that we can
render them and we need to know whether they are 'pending in' or 'pending out'.
We already know they're 'pending out' when ask='subscribe' and
subscription='none'. For 'pending in', since these roster items are only stored
locally and not on the XMPP server (because 'pending in' requests are handled
via <presence> stanzas and not the roster) we add a special attribute
'requesting'.
* 'pending' state is denoted by subscription='none', ask='subscribe'
* 'requesting' state is denoted by subscription='from', ask='subscribe'
Reference: http://xmpp.org/rfcs/rfc3921.html#int
I'm not yet 100% sure with regards to the 'requesting' state, I can't find
anything about it in the above mentioned reference, but apparantly that's what
prosody's roster response looks like (e.g. <item jid='XYZ' ask='subscribe'
subscription='from'/> ).
With ejabberd I haven't yet received such a roster response and contact
requests are always handled via presence stanzas.
updates #81
Use id 'conversejs' instead of 'chatpanel'.
The controlbox toggle is now generated via a backbone view, you don't need to
manually include it in your markup.
When using show_only_online_users, roster item DOM elements are removed from
the DOM if their status changed from 'online' to something else.
When their status changed to 'online' again, they were re-added.
Their views (RosterItemView) instances however didn't listen to events anymore.
Calling delegateEvents on the view after calling $.remove() fixed this.
Users without roster contacts didn't have XMPPStatus.initStatus called and
therefore had a default status of offline.
Fixed this by setting the status to online from the start. The fetch command
will get the true status from localStorage (if available).
Made sure that the rest of converse's onConnected code is called in the
callback from fetch (so that we know the user's status is correct).
Updated and fixed tests.
As a result we now implement more status codes from the spec.
Specifically the codes related to forced removal form the room
Also fixed a bug related to wrong authentication when logging in.
