This change allows the correct number of members to be added when creating a group direct message, based on the site setting chat_max_direct_message_users.
Previously we counted the current user within the max user limit and therefore the count was off by 1.
Before this fix we could only list messages of a thread if it was part of a `threading_enabled` channel or if the thread was set to `force`.
Due to our design of also using a thread id when this is just a chain of replies so we can switch from threading enabled to disabled at any time, we will allow `Chat:: ListChannelThreadMessages` to list the messages of any thread, the only important requirements are:
- having a thread id
- being able to access this thread
To allow this, this commit simply removes the check on `threading_enabled` or `force`.
Under some circumstances, the TextField component could trigger a `Assertion Failed: You attempted to update attrs on ..., but it had already been used previously in the same computation...` error, causing the Ember app to crash.
A few follup changes after changing to the chat footer split for drawer:
* Fixing a bug that stretched the unread indicator on mobile
* Minor style changes in hover/focus behaviour for chat drawer
* Repositioning of unread indicator so it has more space at the top of the footer
* Using the `c-unread-indicator` mixin
Was "removing" (rather not re-applying) the `[spoiler]` BBCode because we were testing the **whole** class of the `span`/`div` was `spoiled` but we added another class and thus broke this functionnality.
In order to fix this issue, the test to determine whether a `span`/`div` is a spoiler, now uses a regular expression to check whether the `class` **contains** the word `spoiled`.
Reference - https://meta.discourse.org/t/quoting-spoiler-text-doesnt-include-spoiler-tags-in-the-quote/170145
Adds a placeholder image + CTA in chat, for empty channel and DM lists.
On desktop with drawer mode, we split chat into tabs (like mobile).
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: David Battersby <info@davidbattersby.com>
Co-authored-by: Régis Hanol <regis@hanol.fr>
In this PR service objects were moved to Core https://github.com/discourse/discourse/pull/26506
However, ServiceRunner should be moved as well. Mostly for CI to run effortlessly without loading plugins.
Prior to this fix we had too logic to detect if a user is active or not:
- idle codepath on the frontend
- online user ids on the backend
The frontend solution is not very reliable, and both solution are just trying to be too smart. Making a lot of people questioning why they receive a notification sometimes and sometimes not. This commit removes all this logic and replaces it with a much more simpler logic:
- you can't receive notifications for channel you are actually watching
- we won't play a sound more than once every 3seconds
The `onNotification` signature is:
```
onNotification(data, siteSettings, user, appEvents)
```
And we were not passing `appEvents`.
Also explicitly inject `currentUser` in `chat-notification-manager` service.
We consider that you should always receive a notification sound when someone speaks directly with you in chat.
This commit also refactors the way we play audio in chat to make it simpler and throttle it to 3 seconds.
We also added a safeguard to ensure we won't play sounds for old messages, this case can happen when message bus is catching up the backlog (eg: in an inactive tab for example).
When users click a link that points to an existing group chat, we should reopen that chat instead of creating a new group chat so users can more easily continue ongoing conversations.
activeChannel is something we should use less and less as it could not exist, in this case we have the channel right here in the function so there's no reason to reach for `this.chat.activeChannel`.
Prior to this fix we wouldn't intercept it, and we also wouldn't handle it, which in result would cause us to handle as a full page interaction and open the full page chat even if you were in drawer mode.
When a user had the chat option "Show activity indicator in header" set to "all new messages", and they would get a reply to a thread they're part of, the chat icon in the header would not show the unread bubble indicator.
In order to fix this, the `ChatHeaderIconUnreadIndicator` component will now `showUnreadIndicator` whenever there is either one unread public channel or there are unread threads.
I only added a system spec for this very specific path because I don't want to slow down the whole suite to test for all the various combination of the `chat_header_indicator_preference` values.
Internal ref - t/128874
Not 100% sure why the changes in `PrettyText.format_for_email` raised this issue, but we were missing adding a link to the Discourse instance whenever we are replacing the elided part of a post with a link to either the post or the Discourse instance in the email.
Also reformated the specs using better variable names (sometimes a variable named `md` would contain some html) and used the `match_html` helper for all the tests.
Given this is currently buggy and we have the cancel button Im not sure this is actually necessary. I feel like it's adding a lot of noise of low value.
For now at least, it's better without it.
This commit reuses the existing codepath in desktop-notifications and make it available to use to chat.
primaryTab was too hard to test if not impossible in this service test, however isIdle and disabled notifications are correctly tested.
Prior to this change, only mentions would get a notification and a sound. This change will not create a notification for this case, but will play a sound. This is still respecting notification settings, not playing the sound when you are viewing the channel or not following it.
---------
Co-authored-by: Régis Hanol <regis@hanol.fr>
(experimental)
The initial implementation of glimmer topic-list and related components. Does not include new APIs and isn't compatible with existing customization. That's gonna come in future PRs.
Enabled by adding groups to `experimental_glimmer_topic_list_groups` setting.
Debouncing the audio was causing the audio to be lost sometimes, somewhat randomly. It's not supposed to be necessary.
The commit also refactors the code to async/await.
Prior to this fix we were using `topic.current_post_number` which is coming from the server side and represents the initial topic scroll position when initially rendered to the end user. However, this value is not dynamic and is not updated when the user scrolls, `topic.currentPost` is the dynamic equivalent.
No test as there are very low chances a test like this one based on scroll position, will be reliable over time.
... wasn't properly escaped so it would should html entities (like `'` instead of the apostrophe `'`).
I checked all the other places we show an excerpt and this was the only one that was missing the call to `htmlSafe` -> `replaceEmoji`.
Internal ref - t/128877
The translations of the labels of some of the chat preferences dropdowns were not customizable via the "site texts" feature.
This was because they were declared outside of a Controller class and were thus not taking into account the customization through "site texts".
Internal ref - t/128859
When you reply to a chat message, we [always create a thread][1]. But when the channel we're in doesn't have threading enabled, the reply is _technically_ not a thread.
This changes the `in_thread?` method to check for both the presence of a `thread_id` and to ensure that the channel has `threading_enabled`.
Internal ref - t/128103/3
[1]: e6e3eaf472/plugins/chat/app/services/chat/create_message.rb (L110-L115)
Whenever you get a bookmark notification, a mention notification, or click on a bookmark on a message in a long thread, we should ensure we always highlight and show the proper message.
Before this fix, we would correctly load the thread, but would always start at the bottom.
Internal ref. t/128103
