A followup to f05b984208
* modifiers to keep track of components' lifecycles, instead of did-insert/did-update/willDestroy
* proper glimmer-friendly tracking in related models
* caching
* `@outletArgs`
* gjs
User options were serialized at the root level of CurrentUserSerializer,
but UserSerializer has a user_option field. This inconsistency caused
issues in the past because user_option fields had to be duplicated on
the frontend.
This allows plugins to colocate component JS and HBS under `/plugins/{name}/assets/javascripts/discourse/components`.
`discourse-presence` is updated to use this new pattern, which also serves as an integration test for this part of the build pipeline.
Before, whispers were only available for staff members.
Config has been changed to allow to configure privileged groups with access to whispers. Post migration was added to move from the old setting into the new one.
I considered having a boolean column `whisperer` on user model similar to `admin/moderator` for performance reason. Finally, I decided to keep looking for groups as queries are only done for current user and didn't notice any N+1 queries.
A follow-up to #15117 and #15141. Applies the previous changes to PM-specific fields, makes the preview area take the all the available height of the composer, and unifies more spacing between composer elements.
Previously the discourse-presence plugin was using a `position: absolute` hack to display the 'replying...' users in the top right of the composer. This commit adds a more suitable plugin outlet, and updates the discourse-presence styling so it slots into the flex-box layout at the top of the composer
I was previously relying on `this.isDestroying` returning `true` during `willDestroyElement`. This was an incorrect assumption.
This commit refactors the logic into an explicit `cleanup` function, and also adds some cleanup for empty keys in the `subscribedProxy` array
This removes all custom controllers and redis/messagebus logic from discourse-presence, and replaces it with core's new PresenceChannel system.
All functionality should be retained. This implementation should scale much better to large numbers of users, reduce the number of HTTP requests made by clients, and reduce the volume of messages on the MessageBus.
For more information on PresenceChannel, see 31db8352
We are working to introduce a general core API for presence, which will clash with this plugin's `/presence` namespace
This commit introduces no functional change. There may be a slight interruption in discourse-presence functionality during a deploy of this commit.
This PR fixes a bug where if you navigate from topic to another one (via suggested topics, notifications etc.), the previous topic is not unsubscribed from presence manager, which means if you visit lots of topics all the subscriptions will accumulate and can cause rate limit errors.
This bug is exposed by the loading slider we're currently experimenting with on Meta because we no longer have an intermediate state when navigating between topics which means the `willDestroyElement` hook that's responsible for unsubscribing is not called.
Previously we were manually comparing the composer 'action' to the REPLY and EDIT constants. This meant that other forms of editing (e.g. shared drafts) were not included. This commit changes the presence logic to use the existing composer computed variables.
This will make a few minor improvements to the second factor user interface. Highlights include:
- Using the site's title to prefix the backup code filename. If non-ascii characters are detected, then prefix "discourse" instead.
- Add icons and change the text on some of the buttons for better clarity and consistency
- Add an education link to the security key modal
This change amends it so we use a static service to keep track of
the typing presence.
It correct various edge cases the initial implementation had
- Faster close messages
- When composing on topic 1 and viewing topic 2 we had incorrect
presence
- Changing a running composer to reply as new topic or reply to a
differet topic would not correctly shift presence
Authored by tgxworld, with contributions by sam
Before this commit, the presence state of users were stored on the
server side and any updates to the state meant we had to publish the
entire state to the clients. Also, the way the state of users were
stored on the server side meant we didn't have a way to differentiate
between replying users and whispering users.
In this redesign, we decided to move the tracking of users state to the client
side and have the server publish client events instead. As a result of
this change, we're able to remove the number of opened connections
needed to track presence and also reduce the payload that is sent for
each event.
At the same time, we've also improved on the restrictions when publishing message_bus messages. Users that
do not have permission to see certain events will not receive messages
for those events.
