Unread messages: Detailed processus

closed

By Jean-Baptiste Pasquier on 2020-02-19T14:11:04 (imported from GitLab project)

reopened

By Jean-Baptiste Pasquier on 2020-02-19T14:11:05 (imported from GitLab project)

added 1 deleted label

mentioned in issue management/sip-app-management#1

First version of the custom converse plugin for room activity indicators based on the protoXEP by @MattJ

I need to do some more testing and then it should be ok to use.

Fine, thanks. Keep us up-to-date when it'll be ready for integration.

Finished testing it for now. I created an Openfire plugin to test the XEP outside of Prosody. It should be ready for integration. I added browser notification for my tests. You can disable that or remove if not applicable to SiB Chat.

Great! I'll wait update from @MattJ for server side before integrate it on sib-chat.

mentioned in issue #21 (closed)

mentioned in issue #122 (closed)

mentioned in issue #123 (closed)

mentioned in issue #124 (closed)

The Prosody implementation is working except for one minor bug that may cause notifications to not be sent in all cases, I will fix this tomorrow.

It should be noted that I don't currently have a plan for deploying this to the current server. It requires a Prosody upgrade, which is not something I think I have done before on this server.

I also intend to prioritize working on the new container-based Prosody deployment, which will make this much easier.

The module is now finished. It just need to be deployed.

Unfortunately it won't work with the version of Prosody currently deployed on the server. I can spend time figuring out how to update Prosody, or I can put my effort into the container-based deployment.

@rachel @jbpasquier please let me know the priority of deploying this vs. working on the new deployment stuff (infra/platform#42 (closed)).

Assuming that you handle this migration entirely with Plup and any assistance you may need, and that you already started it, could you provide us a deadline for this migration?

This is what will answer your question, if it's too long, we'll want an upgrade, fixes and this feature on the current one. Else, let's go this way.

I expect the migration to take most of my time for the next couple of weeks. If I need to spend time updating the current server, that will obviously delay the migration work (I'm afraid I can't estimate that easily - maybe a few days of work to upgrade the current server).

Ok, I took a look through the current server. I think I can probably transition to a more reliable and easy-to-upgrade setup within a few hours. It may require a short amount of downtime, maybe up to 30min to be on the safe side.

Is there a time that would be acceptable to do? Do we need to schedule a maintenance window? (weekend is ok for me if necessary).

Few hours sounds good, right. :-)

@rachel I let you choose a perfect timing for a chat shutdown.

I have no vision of the best timing as we don't have Matomo set up yet. Are we able to know what's the time window during which our users use the most the chat in another way?

Otherwise the best would be to set up a time that suits you @MattJ but tell me in advance so that I can warn our instances managers 1 or 2 days in advance.

Let's say Saturday at 4-6pm Paris time. I'm not planning for it to be down entirely during this period, I'll aim to keep disruption to a minimum, but there may be some period where the chat is unavailable.

If I have any problems, it will be easy enough to roll back to the previous setup.

Alright thanks @MattJ

mentioned in issue #140 (closed)

The module that implements the new protocol is now deployed and running on the server.

@jbpasquier over to front-end folk :)

assigned to @jbpasquier and unassigned @MattJ

Implemented on https://git.startinblox.com/applications/sib-app/tree/feature/unreads using sib-chat@0.6.

Pretty much buggy. Chats are always marked with unread if there are any message on them on app load. Even if I read a channel, on page reload the event is sent again.

I had a chat yesterday with @MattJ and @deleolajide about that, some tracks are currently followed like send a marker for the last received markable message on join.

Explanation:

Prosody needs to determine which rooms have "activity" so it knows what notifications it needs to send. Therefore Prosody needs to know which messages the client/user has read to.

Apart from an initial trivial bug which is now fixed, notifications seem to be working.

The missing piece is that Converse.js currently doesn't notify Prosody that the user has read messages if they were loaded from the history. This is reasonable (there may be many messages fetched from the history, and we don't want it to acknowledge each one individually!).

There are two primary fixes I see:

Converse.js (or a plugin) notifies Prosody after the room join, what point the history was loaded to. This allows Prosody to mark the messages as read on the server side, and no longer generate notifications for that room
Prosody automatically marks all messages as read when the user joins the channel.

I prefer the first solution, because it is more "correct", but the second will work in most cases (except when the client gets disconnected before all messages have been shown to the user).

@deleolajide Using you latest version of the RAI plugin, it does not trigger the event now, never.

Logged in as admin on test3, Hello Canal 1 is open. I login on a private session with jbpasquier and send a message on Hello Canal 2. No event on admin.

Related log:

 2020-05-04T12:24:27.189Z DEBUG: request id 3.1 state changed to 2 converse.min.js:1:513414
 2020-05-04T12:24:27.191Z DEBUG: request id 3.1 state changed to 3 converse.min.js:1:513414
 2020-05-04T12:24:27.192Z DEBUG: request id 3.1 state changed to 4 converse.min.js:1:513414
 2020-05-04T12:24:27.192Z DEBUG: removing request converse.min.js:1:513414
 2020-05-04T12:24:27.192Z DEBUG: _throttledRequestHandler called with 0 requests converse.min.js:1:513414
 2020-05-04T12:24:27.192Z DEBUG: request id 3 should now be removed converse.min.js:1:513414
 2020-05-04T12:24:27.193Z DEBUG: request id 3.1 got 200 converse.min.js:1:513414
 2020-05-04T12:24:27.193Z DEBUG: _dataRecv called converse.min.js:1:513414
 2020-05-04T12:24:27.193Z DEBUG: <body xmlns="http://jabber.org/protocol/httpbind" xmlns:stream="http://etherx.jabber.org/streams" sid="c55c3915-7798-429e-a365-e447db044b4e"><message id="14764133-07cc-4ea4-a74a-26af8d34b3e0" xml:lang="en" type="groupchat" xmlns="jabber:client" to="admin@test3.startinblox.com/converse.js-54855987" from="mlc2gg1bqjqh@conference.test3.startinblox.com/jbpasquier"><body>Hey</body><active xmlns="http://jabber.org/protocol/chatstates"/><origin-id xmlns="urn:xmpp:sid:0" id="id92e01187-064f-49fb-b8e3-c2bc5bedadb8"/><stanza-id xmlns="urn:xmpp:sid:0" by="mlc2gg1bqjqh@conference.test3.startinblox.com" id="14764133-07cc-4ea4-a74a-26af8d34b3e0"/><markable xmlns="urn:xmpp:chat-markers:0"/></message></body> converse.min.js:1:513414
 2020-05-04T12:24:27.267Z DEBUG: no requests during idle cycle, sending blank request converse.min.js:1:513414
 2020-05-04T12:24:27.267Z DEBUG: _throttledRequestHandler called with 1 requests converse.min.js:1:513414
 2020-05-04T12:24:27.267Z DEBUG: request id 4.0 posting converse.min.js:1:513414
 2020-05-04T12:24:27.268Z DEBUG: request id 4.0 state changed to 1 converse.min.js:1:513414
 2020-05-04T12:24:27.268Z DEBUG: <body rid="4167478736" sid="c55c3915-7798-429e-a365-e447db044b4e"/> converse.min.js:1:513414

assigned to @deleolajide and unassigned @jbpasquier

closed

Unread messages: Detailed processus

Designs

Child items ...

Activity