Don
November 13, 2024, 6:23am
1
Hello
I’ve found some places where I think it should hide online presence too.
Chat presence, when you write a message it show on the bottom even if you hide your presence.
I think on user page summary, in statistics the Seen section should also be hidden for users if hide presence active.
It would also be good if it works like the 2 point with the “Last Seen” User Card theme component.
Thanks
4 Likes
lindsey
(Lindsey Fogle)
November 21, 2024, 3:35pm
2
Thanks for sharing these ideas! I’m going to move this to Feature though, since these would involve expanding our current functionality beyond UX adjustments.
1 Like
zogstrip
(Régis Hanol)
December 3, 2024, 8:55pm
3
Don:
Chat presence, when you write a message it show on the bottom even if you hide your presence.
This will be fixed by
discourse:main
← discourse:fix-is-replying-when-offline
opened 06:57PM - 03 Dec 24 UTC
While trying to reproduce an issue reported internally where a user saw the "is … replying..." from another user who had disabled presence (aka. was "offline"), I noticed something odd about the way we "notify" presence via `notifyState`. The way it is setup up, it's being called on every "input" event in the composer/editor, due to it tracking the "reply" property of the composer model. That's fine, but the way the `helperFn` helper works, make it so we're calling the `on.cleanup` callback also on **every** "input" events in the composer/editor. For every character we enter in the composer, we're "entering" the presence channel and immediatelly "leaving" it...
If I remove the checks on `reply` (and thus the auto-tracking), then the `notifyState` function is called much less frequently. But we have some specs that expects us not to "publish" our presence when we open the composer and the reply is "empty".
Note: I switched to using `replyDirty` instead to re-use the checks the composer model is already doing to ensure we actually have changed something in the reply.
The best I came up with was not to rely on the `helperFn` but now, there's no way (that I could find) to call `composerPresenceManager.leave()` when the composer is closed. I tried a lot of different ways, but none worked. I'm sure it's something stupid easy, but I can't figure it out just now.
FIX: Deleted the "ChatComposerPresenceManager" since it was mostly duplicating the work the "ComposerPresenceManager" was doing. So now the #chat composer uses the same "presence manager" as the composer, benefiting from the "hide presence" checks, with the only difference that the "keep alive" timeout is 5s for chat and 10s for topics/posts.
FIX: In 09932738e5f0121866c2d6be44ce6ecf40f4e3d0 we introduced the `whisper_allowed_group_ids` to allow whispers to more users than "staff". The presence plugin hadn't been updated to account for this change.
PERF: Also slightly improved the performance of the `Roleable.whisperer?` check to do a Ruby intersection between two arrays instead of asking the database.
Internal ref - t/127490/74
(once I manage to get it to work properly )
2 Likes
zogstrip
(Régis Hanol)
December 4, 2024, 2:16pm
4
chat presence should respect the online/offline toggle now that it uses the same “presence manager” as “core”.
committed 11:21AM - 04 Dec 24 UTC
...since it was mostly duplicating the work the "ComposerPresenceManager" was do… ing.
So now the #chat composer uses the same "presence manager" as the composer, benefiting from the "hide presence" checks, with the only difference that the "keep alive" timeout is 5s for chat and 10s for topics/posts.
3 Likes