- 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.
- 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
Avoid `An 'url' property must be specified` error by properly clearing
presence data upon teardown and then resetting the browserStorage upon
reconnection.
Store contact resources in a Backbone collection
by not flushing stanzas when sending out an <inactive> CSI.
When reloading the page, the stanzas are resent (because we never had
time to receive acks) which causes problems on Prosody (and likely also
causes the Ejabberd "other-request" errors).
So that we first render dynamic content (e.g. images) before inserting
it into the chat.
Also, add the `show_images_inline` setting (which is the cause of this
whole change).
Updated tests to handle this new change and start using async/await
instead of promise callbacks.
We now have uniform avatar rendering for the profile, messages and
chatboxes.
By rendering as canvas, we can avoid stretching the image.
In the process I also moved the ChatBoxViews collection into its own
plugin `converse-chatboxviews` and placed the AvatarAware views there.
fixes#1157
The `_converse.session` store gets cleared after logout, but we want the
`trusted` flag to persist after logout.
Also update the documentation no that the `storage` config option has
been removed in favor of `trusted`.
So that it persists across page loads. Otherwise storage falls back to
the default, causing records to be in both local- and sessionStorage.
Additionally, update singleton models to have the 'id' available as a getter.
Otherwise multiple records gets stored in browserStorage, causing random
results being returned.
Include entity capabilities hash in outgoing presences
Also, started some work on using jsdoc for rendering API documentation.
Ideally that would go into a separate commit but that would take ages to
untangle.
And instead implement it ourselves.
This solves a bug with that plugin whereby the connection handlers are
added to early and are therefore never fired.
Also fixed a problem whereby entity items are queried for features
before the features have been fetched.
Entity items weren't being fetched from cache.
Apparently this bug only surfaced because with Ejabberd the upload
service is nested one level deeper than with Prosody.
- set `username` on the message object,
instead of always using `fullname` with fallback to `jid`.
- Distinguish better between `groupchat` messages and normal
messages in `getMessageAttributesFromStanza`
- Render images as thumbnails
- Use the image.html template when rendering images from pasted URLs
- Update message and spoiler markup to render avatars
- Use the default avatar as fallback when user doesn't have one
- Instead of 'me' render own name or JID
To make it more similar to how messages are sent in private chats and to
reuse methods as far as possible.
Removed `sendChatRoomMessage` and `clearChatRoomMessages`
Specifically the methods related to requesting an upload slot and uploading a file.
Also show a progress indicator while a file is being uploaded.
Updates #161
It contained only `overrides` and some HTTP upload code was in other
modules.
Current thinking concerning overrides:
Usage of `overrides`, while useful in certain cases, should in general
be discouraged, since it's in essence "monkey patching" which makes it
more difficult to know whats executing at runtime and more difficult to
refactor.
Splitting modules up between XEPs is not always that useful. Some XEPs,
like HTTP Upload (and MAM comes to mind) have their functionality spread
out over single and group chats (and pubsub) and might for practical
purposes be considered "core" enough to not try and keep them in
separate modules (which inevitably requires overrides or a fundamentally
rethinking the architecture).
Where splitting code between modules makes a lot of sense is in keeping
Backbone Models and Views separate (so that alternative view libraries
like Vue could be used) and probably in keeping Single chats, MUC,
PubSub and MIX separate.
updates #161
* Use Promises instead of callbacks
* Update to latest (Last Call) version of XEP-0363
* Move non-view specific methods to models instead
* Add more tests
updates #161
Previously we kept all entities and their items (which are also
instances of _converse.DiscoEntity) in a flat array.
Instead, we should have a tree-like structure where items are stored
on the relevant entity (and recursively on other items).
