Every time a desktop chat sound plays, there should be some visual cue as to why the sound was played in the first place.
This change follows the chat indicator preference:
- All New Messages - a blue dot is shown for all messages, so we attempt to play a sound every time
- Direct Messages, Mentions and Watched Threads - a green dot is shown for all urgent messages, so we attempt to play a sound for urgent chat notifications
- Only Mentions - only play chat sounds when user is mentioned
- Never - we never play chat sounds, as user wouldn’t know why the sound was played
Chat toggle relies on using a height: auto to collapse drawer, however in channel threads we should be only displaying threads when drawer is expanded. Displaying threads conditionally based on drawer toggle status fixes this.
This change increases the visibility of unread channels to make them stand out more in drawer mode (desktop).
When a channel is unread:
- it floats to the top;
- when multiple channels are unread, they are sorted alphabetically (equal to how it’s done on mobile)
- the unread indicator blue dot moves to directly right of the channel name
This patch removes the `with_service` helper from the code base.
Instead, we can pass a block with actions directly to the `.call` method
of a service.
This simplifies how to use services:
- use `.call` without a block to run the service and get its result
object.
- use `.call` with a block of actions to run the service and execute
arbitrary code depending on the service outcome.
It also means a service is now “self-contained” and can be used anywhere
without having to include a helper or whatever.
We need to start printing deprecation notices when the `show_in_ui` argument is used because it works only for the old about page which will be removed soon. For the new about page, we've introduced a new API `addAboutPageActivity` which is more flexible than a true/false argument on the server side.
Internal topic: t/136551.
Currently, categories support designating only 1 group as a moderation group on the category. This commit removes the one group limitation and makes it possible to designate multiple groups as mods on a category.
Internal topic: t/124648.
A new setting attribute is used to define the areas (separated by `|`).
In addition, endpoint `/admin/config/site_settings.json` accepts new `filter_area` data.
This change introduces a new thread notification level allowing users to get notified when someone replies to the thread.
Users who watch a thread will get a green notification on the chat icon and a user notification (blue). User notifications are consolidated based on thread id to prevent cluttering the original users notification area.
---------
Co-authored-by: Régis Hanol <regis@hanol.fr>
We're working to remove all decorators from object-literal-properties. This commit refactors all initializers which were using these decorators into classes, where decorators are allowed. Also adds cleanup logic to the local-dates initializer, which was previously missing.
Removes chat-specific changes from dfc947a97d, and adds `preventScroll: true` to prevent timing issues between the emoji picker being brought into the viewport and being focussed.
Now that `ActiveRecord` relations are properly handled in a `model`
step, putting this step back will allow the service to stops its
execution if there are no users to be removed without calling the pretty
big SQL query contained in the `CalculateMembershipsForRemoval` action.
When we use CTRL/CMD + K to search, on the server we run 4 queries:
- 1 for users
- 1 for groups
- 1 for category channels
- 1 for direct message channels
The server returns up to 10 results per type and the client concatenate all the results (in the order I described) and then takes the first 10 or so.
Let's say you've had 1:1s with john1, john2, and john3. Searching for “john” would return all the johns as “users”. It doesn’t make sense to also return them as 1:1 dms.
That’s what this fixes. When the search returns some users, we skip all 1:1s because we assume they will show up as the results of the “users” query.
We’ll always return matching direct messages with more than 2 users (aka. “group chats”). All 3 other queries (users, groups, and category channels) are unaffected.
Internal ref - t/136079
This patch allows using an AR relation as a model in services without
fetching associated records. It will just check if the relation is empty
or not. In the former case, the execution will stop at that point, as
expected.
This commit introduces a new frontend API to add custom items to the "Site activity" section in the new /about page. The new API is called `addAboutPageActivity` and it works along side the `register_stat` serve-side API which serializes the data that the frontend API consumes. More details of how the two APIs work together is in the JSDoc comment above the API function definition.
Internal topic: t/128545/9.
This commit improves the hilight-ing of mentions in posts and chat messages.
- `@here` and `@all` will generate a `<a class="mention --wide">`
- bots will generate a `<a class="mention --bot">`
- current user will generate a `<a class="mention --current">`
To achieve this change the following value transformer has been added: "mentions-class". It will be run in posts and chat messages after the mention is rendered.
A bug were bots were not considered in mentioned users has also been fixed as part of this PR.
This is a variation on bc3e8a9963cf9a64d114ec751c875025af169690, which was reverted due to issues on iOS. Safari's "in response to user action" check cannot follow the `runAfterFramePaint` chain of interaction -> requestAnimationFrame -> messageChannel, and so some sensitive browser APIs (e.g. clipboard, upload, etc.) were blocked.
This commit is similar, but uses `next()` instead of `runAfterFramePaint()`. The result seems the same, but doesn't have the same issue on iOS.
The chat-emoji-picker change was required to resolve a test failure. The emoji picker has never closed-on-scroll on desktop, so there is no user-facing change in behavior.
This is a follow-up to 671f40ce07 and
ed11ee9d05.
While the optimisations in the previous commits were sound, it did not
resolve the memory bloat we were seeing. It turns out that we call
`.blank?` on the model's result if the model has not been marked
optional. The problem with this is that if the model returns an
ActiveRecord relation, calling `.blank?` on the relation basically loads
everything into memory.
Therefore, this commit removes `users` as a model in the since it really isn't
a model but just a relation.
This is a follow up to ed11ee9d05.
In `Chat::AutoRemove::HandleCategoryUpdated`, we are currently loading
the related users record in batches and then handing it off to
`Chat::Action::CalculateMembershipsForRemoval.call`. However, we are
still seeing memory spike as a result of this.
This commit eliminates the allocation of `User` ActiveRecord objects until
absolutely necessary. `Chat::Action::CalculateMembershipsForRemoval.call` has been
updated to accept an ActiveRecord relation instead which allows us to
avoid the ActiveRecord allocations.
This change delays the notify watching job to allow time for message to be marked as seen within chat.
Without a slight delay the job fires straight away and often means that messages are seen on screen but the user also receives a notification due to Chat::Notifier.user_has_seen_message? returning false.
This commit seeks to reduce the memory footprint of `Chat::AutoRemove::HandleCategoryUpdated.call`
by optimizing the
`Chat::AutoRemove::HandleCategoryUpdated#remove_users_without_channel_permission` method which was
loading all the ActiveRecord users objects into memory at once. This
change updates the method call to load the ActiveRecord user objects in
batches instead.
Adds a new statistics (hidden from the UI, but available via the API) that tracks daily participating users.
A user is considered as "participating" if they have
- Reacted to a post
- Replied to a topic
- Created a new topic
- Created a new PM
- Sent a chat message
- Reacted to a chat message
Internal ref - t/131013
This outlet is rendered before the content of the drawer. The `currentRouteName` is accessible in `outletArgs`.
Example:
```gjs
export default class Test extends Component {
<template>
{{#if (eq @outletArgs.currentRouteName "chat.browse")}}
the browse page
{{/if}}
</template>
}
```
* FIX: make the check better for drawer rerouter
* adds a redirect method to chat-drawer-routes
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Kris
David Battersby
Joffrey JAFFEUX
Loïc Guitaut
Osama Sayegh
Discourse Translator Bot
Krzysztof Kotlarek
David Taylor
Renato Atilio
Jan Cernik
Alan Guo Xiang Tan
Régis Hanol
Sam
chapoi
Mark VanLandingham
Gabriel Grubba