Includes some refactoring:
- Don't send an `active` chat state notification when entering a MUC
I can't think of a good reason why this might be necessary or desired.
- Move `setChatState` form the view to the model
- Remove unused method `handleChatStateNotification`
- Don't store `role` and `affiliation` for the current user on the
ChatRoom object, but instead on the ChatRoomOccupant object representing
the user.
In some cases, it might be desirable to clear cached chat messages once you've
reconnected to the XMPP server.
For example, if you want to prevent the chat history from getting too long or
if you want to avoid gaps in the chat history (for example due to MAM not
returning all messages since the last cached message).
If you're using OMEMO, then you probably don't want to set this setting to
``true``. OMEMO messages can be decrypted only once, so if they then
subsequently get cleared, you won't get the plaintext back.
Only fetch messages after we have the latest room features
Otherwise we run into race conditions where MAM messages are fetched
before we know whether (updated) the room supports MAM or not.
- Fixes#1575. Height not properly set on MUC invitation list
- Add new configuration setting: `muc_mention_autocomplete_min_chars`
- Bugfix. `min_chars` setting for MUC mentions wasn't having an effect
* Checkmark and edit modal button are now on the right
* Instead of showing checkmarks for MUC messages,
we now show them as light grey before MUC reflection
* Simplify message markup by requiring less `if` statements
- new config option `singleton`.
- new plugin `converse-uniview`
- removed `converse-embedded`.
- various CSS changes, to properly render an embedded full app
- don't re-open cached and non-autojoined chats in singleton mode
The goal here is to extend the `embedded` `view_mode` so that the full app can
also be embedded, not just a single MUC or private chat.
To do this, we'll need to differentiate between multi and singleton chat apps.
* A singleton chat app contains only a single chat.
* A multi-chat app can contain zero or more chats
So we introduce a new config option, `singleton`, which when used with
`view_mode` set to `embedded` will determine whether a single chat or the full
app is embedded.
Similarly, in `overlayed`, `fullscreen` and `mobile` view modes, `singleton`
set to true will allow only one chat within the parameters of that view mode.
We're appropriating the word `singleton` and introducing the concepts of
`uniview` and `multiview` (see a785ca8) to cover what was
previously meant with `singleton`.
updates #1297
- Use native `getTime` method instead of moment's `valueOf`
- Use toISOString() instead of moment().format()
This makes the code timezone independent since we're now globally using UTC.
Messages (received directly or via MAM) are stored in a backbone
collection that's kept sorted by the message's "time" attribute.
Various parts of the codebase rely on this behavior.
For regular messages, the time attribute is generated by
`moment().format()`, which generates a timestamp in the browser's
local timezone, for example "...+02:00".
For MAM messages, we would previously copy the "delay.stamp" value
into the "time" attribute verbatim. However, that value is generated
by the server and is unlikely to be in the same timezone locale.
ISO timestamps expressed in different timezones cannot be sorted
lexicographically, breaking the premise of keeping the messages
collection sorted by time.
- Let box_id start with char for valid HTML.
- No need to use SHA1 for box id
- No need for the user_id attribute.
- Set nickname when we set the roster contact.
Also...
- _converse.api.contacts.get is now async
- _converse.api.chats.create is now async
This changes the API method's current behavior by not automatically
maximizing (in `overlayed` view mode) or bringing a background chat into
foreground (in `fullscreen` view mode). Instead `force` needs to be set
to `true` for that to happen.
Set reference to roster contact on the message and chatbox object and
listen for changes to the nickname.
Currently, because chat boxes are fetched and initialized before the
roster, messages and chats are repainted with the correct display name
only later, causing a "flash" effect.
Ideally we would only initialize the chat boxes after the roster
contacts have been fetched, but this is currently not easily possible
because we need the control box to render before everything else.
Until now, we've only been explicitly documenting the `_converse.api`
namespace and only considered the methods under it as forming the API
contract (which determines how we do semver releases).
It appears as if we've reached a point where trying to keep everything
under the `_converse.api` namespace no longer makes sense. Certain
methods are applicable to particular models and trying to shoehorn them
into the `_converse.api` namespace seems clunky and non-intuitive.
I've therefore decided to slightly refactor `sendMessage` to let it take
two simple parameters and to document it with JSDoc so that it's
presented as an API method, albeit only available on a chat model.
updates #1496
updates #1504
Eventually we need to add better support for receipts and markers of MAM
messages.
We'll need to do the following:
* First check whether the MAM page already contains the receipts or markers, to avoid duplication
* Only ever in catchup mode
* Only after full catchup to ensure that the receipt is not in a different page than the message
Don't check for older messages with same msgid
we can't rely on a message's `id` attribute being unique.
Also, remove `createMessage` in favour of calling `messages.create` directly.
When OMEMO isn't possible, render it as grey.
This change makes OMEMO for MUCs easier, since there I anticipate that
OMEMO support might change dynamically based on who enters/exits the
room.
updates #1180
