Otherwise we might run into a situation where a very old,
cached MUC that's being restored has `connection_status` set to ENTERED
(and the user happens to be in the MUC via another client)
and then restores cached messages without taking
`clear_messages_on_reconnection` into account.
We now distinguish more clearly between joining and re-joining a MUC.
The `enterRoom` method has been refactored away.
Instead, `join` or `rejoin` should be used, depending on the circumstances.
Don't fetch cached occupants in the `initialize` function, instead, only fetch
them if we're restoring a MUC that we're still connected to.
If we're not restoring a still-connected MUC, then we clear the
occupants cache, and the messages cache if `clear_messages_on_reconnection` is `true`.
updates #1807
updates #1808
- Add config variable `muc_show_logs_before_join`
- Restore nickname form for the original use-case (when not showing MAM logs before joining).
- Render nickname form in the `.muc-bottom-panel` when showing MAM logs (instead of in a modal)
- Show a message when there aren't any archived messages to show
- Fix converse-mam so that chat logs are properly fetched before entering a MUC
closes#1266
- Add support for switching ephemerality after message creation
- Move more methods from ChatBox and ChatRoom to utils/stanza.js
- Rename 'ephemeral' to 'is_ephemeral' since it's a boolean
- Move headless one-on-one chat functionality into converse-chat
- Split converse-headline into converse-headlines and converse-headlines-views
- Add api in `_converse.api.chatboxes` for creating chatboxes
- Add `_converse.api.controlbox.get` method
VCards were being created before `fetch` was completed, so once fetch
was done those VCards were unset from their collection.
Add a new event and promise `VCardsInitialized` that triggers after
successful fetching and wait for it before creating VCards.
Depend on latest backbone.browserStorage which has support for IndexedDB
via localforage.
Storage operations are now asynchronous and transactional.
Bugs fixed (mostly by waiting for operations to complete):
* Rooms are now fetched asynchronously, so wait before triggering `show`
or when closing.
* Make sure chat create/update transactions complete before firing events
* Make sure chats and messages have been fetched before creating new ones.
* When doing a `fetch` with `wait: false` on a collection and then
creating a model in that collection, then once the read
operation finishes (after creating the model), the collection is emptied again.
* Patch and wait when saving.
Otherwise we have previously set attributes overriding later ones.
* Make sure api.roomviews.close returns a promise
Test fixes:
* Chats are now asynchronously returned, so we need to use `await`
* Wait for the storage transaction to complete when creating and updating messages
* Wait for all chatboxes to close
Otherwise we get sessionStorage inconsistencies due to the async nature of localforage.
* Wait for room views to close in spec/chatroom.js
In the process, remove the `closeAllChatBoxes` override in
converse-controlbox by letting the `close` method decide whether it
should be closed or not.
Lately we've been fetching messages only after entering the MUC, so that
we already have occupants to attach to them (due to `fetchMembers` being
called before) and thereby avoid rerenders.
I've now moved message fetching into the `initialize` method and added
missing event handlers for attaching/removing the occupant from a
message as it comes online or goes offline.
We still avoid (some) rerenders because we fetch and wait for cached
occupants before fetching cached messages and we wait for `fetchMembers`
before triggering `enteredNewRoom` which causes MAM messages to be
fetched.
We want to fetch messages from cache only once. For one-on-one chats
this is the case because messages are fetched only in the `initialize`
method.
This used to be the case for MUCs as well, until we added the option
`clear_messages_on_reconnection`.
Now we only fetch messages after the user has entered the MUC.
in which you can set user affiliations and roles.
Also, let getAffiliationList return an Error instead of `null` if you're
not allowed to fetch a particular affiliation list.
Don't remove affiliation for occupants if we weren't allowed to
fetch that particular affiliation list.
Previously, if fetching the list failed, we would return an empty array,
which would imply that the affiliation list is empty and that all
users with the given affiliation should have their affiliations removed.
Instead we now return `null` and properly account for that when setting
affiliations on existing contacts based on the returned member lists.
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.
This is done to avoid unnecessary repaints and reflows (caused when a
message has already rendered and then an occupant is created and
attached to that message, cauring a re-render).
Related to #1266
and re-enter if necessary.
This solves the problem where we "clone" a tab (e.g. middle-click) and
then restore a MUC from cache which we haven't actually entered (given
that the new tab represents a new device and session).
Also... add `await` in a test to try and fix Travis flakiness
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
