This commit introduces <NotificationsTracking /> which is a wrapper component around <DMenu /> which replaces the select-kit component <TopicNotificationsButton />.
Each tracking case has its dedicated component:
- topic -> `<TopicNotificationsTracking />`
- group -> `<GroupNotificationsTracking />`
- tag -> `<TagNotificationsTracking />`
- category -> `<CategoryNotificationsTracking />`
- chat thread -> `<ThreadNotificationsTracking />`
In this PR, we added functionality to hide the admin header for edit/new actions - https://github.com/discourse/discourse/pull/30175
To make it work properly, we have to rename `show` to `edit` which is also a more accurate name.
This change creates a shallow copy of the public message channels so we don't change the original array while sorting.
Without this change the publicMessageChannels getter cache gets invalidated and cached again with the sorted channels array instead, which causes a bug where the sidebar channel list sorting order is updated by activity when user interacts with the chat drawer.
Some users are seeing consistent "Error 5" crashes in chrome when saving/deleting bookmarks on chat messages.
When crash logging is enabled, the message is:
`[33466:259:1206/122312.195048:ERROR:ax_object.cc(3400)] Check failed: !NeedsToUpdateCachedValues(). Stale values: "Group" axid#7543 <svg#discourse-emojis> needsToUpdateCachedValues/disallowed isIgnored inUserAgentShadowRoot:<use> isInert needsToUpdateChildren hasDirtyDescendants`
This seems to be influenced by a few factors, including the re-render of the bookmarks button, the adjacent 'reactions' button, and also the opening/closing of the modal.
Adding this `activeElement.blur` seems to avoid the issue in my manual testing. Hopefully, this can be dropped after future chrome releases.
Internal topic: t/143485
Follow up to #30127.
Normally when viewing a channel with tracked threads, we dismiss the blue dot next to the channel name even though the thread has not been read yet.
This change applies the same criteria to determine if we should bold the channel name.
This change sorts unread channels in descending order based on last message date, so channels with the latest activity will always appear at the top. It also adds some improvements for sorting channels with unread threads, now when multiple channels have unread threads, they will be sorted by last thread reply date to ensure more active channels rise to the top.
For DM channels, the order is now:
- Urgent (green badge) - unread messages, mentions and unread watched threads (most recent activity at top)
- Unread (blue badge) - unread tracked threads (most recent thread reply at top)
- Everything else (most recent message at top)
...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.
This will ensure AI generated titles don't appear as out of range in the UI and also allow users to set longer titles. The limit in DB was already 100 so it's just a simple frontend change.
We were using a complex logic to make it change size based on scroll position but this was imperfect and not visually pleasing. Also the title had been made a button which was causing the ellipsis to not work correctly, and I would prefer to not mix page knowledge (thread) with title component so I made this click logic directly in the chat-thread component.
---------
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
Historically the behavior of this file has been complexified to attempt to answer this use case:
A user has two tabs open, tab 1 is on a topic, tab 2 is on a chat channel. If your active tab is tab 1 and someones sends you a mention in chat. We will show a desktop notification, but in which tab the channel should open if you click it? The changes made years ago said: in tab 2.
I think this is complexifying too much this codepath and is also confusing. You might wonder why this discourse notification you clicked opened in some of your 50 tabs in the background when you had a discourse tab active currently in front of you.
Moreover, a recent change has made the notification to only happen on desktop, but all the subscription stuff was happening regardless of mobile or desktop.
- Clicking the channel title of a collapsed drawer will only open the drawer, and not open settings
- Remove the back button when the drawer is collapsed
- Uses same icon for toggling on chat that composer
- add max-width to minimised drawer + add hover effect
---------
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
In particular, this applies:
- new `discourse/no-implicit-this` template-lint rule
- `init`/`willDestroy` ordering enforcement
- `lines-between-class-members`
Blocks allow BOTS to augment the capacities of a chat message. At the moment only one block is available: `actions`, accepting only one type of element: `button`.
<img width="708" alt="Screenshot 2024-11-15 at 19 14 02" src="https://github.com/user-attachments/assets/63f32a29-05b1-4f32-9edd-8d8e1007d705">
# Usage
```ruby
Chat::CreateMessage.call(
params: {
message: "Welcome!",
chat_channel_id: 2,
blocks: [
{
type: "actions",
elements: [
{ value: "foo", type: "button", text: { text: "How can I install themes?", type: "plain_text" } }
]
}
]
},
guardian: Discourse.system_user.guardian
)
```
# Documentation
## Blocks
### Actions
Holds interactive elements: button.
#### Fields
| Field | Type | Description | Required? |
|--------|--------|--------|--------|
| type | string | For an actions block, type is always `actions` | Yes |
| elements | array | An array of interactive elements, maximum 10 elements | Yes |
| block_id | string | An unique identifier for the block, will be generated if not specified. It has to be unique per message | No |
#### Example
```json
{
"type": "actions",
"block_id": "actions_1",
"elements": [...]
}
```
## Elements
### Button
#### Fields
| Field | Type | Description | Required? |
|--------|--------|--------|--------|
| type | string | For a button, type is always `button` | Yes |
| text | object | A text object holding the type and text. Max 75 characters | Yes |
| value | string | The value returned after the interaction has been validated. Maximum length is 2000 characters | No |
| style | string | Can be `primary` , `success` or `danger` | No |
| action_id | string | An unique identifier for the action, will be generated if not specified. It has to be unique per message | No |
#### Example
```json
{
"type": "actions",
"block_id": "actions_1",
"elements": [
{
"type": "button",
"text": {
"type": "plain_text",
"text": "Ok"
},
"value": "ok",
"action_id": "button_1"
}
]
}
```
## Interactions
When a user interactions with a button the following flow will happen:
- We send an interaction request to the server
- Server checks if the user can make this interaction
- If the user can make this interaction, the server will:
* `DiscourseEvent.trigger(:chat_message_interaction, interaction)`
* return a JSON document
```json
{
"interaction": {
"user": {
"id": 1,
"username": "j.jaffeux"
},
"channel": {
"id": 1,
"title": "Staff"
},
"message": {
"id": 1,
"text": "test",
"user_id": -1
},
"action": {
"text": {
"text": "How to install themes?",
"type": "plain_text"
},
"type": "button",
"value": "click_me_123",
"action_id": "bf4f30b9-de99-4959-b3f5-632a6a1add04"
}
}
}
```
* Fire a `appEvents.trigger("chat:message_interaction", interaction)`
When using chat in drawer mode, after you've clicked on a chat bookmark in the user menu, clicking any other chat bookmark would "do nothing".
In 8b18fd155679fa9b9d6e660ac74130cb79daabdc we added an optimization to prevent the same route from being reloaded, but it ended up breaking the bookmarks.
This commit reverts the changed made the above commit and adds a system specs that ensure we can click two chat bookmarks in the user menu when using chat in drawer mode.
Internal ref - t/134362
Previously we only counted mentions that were made within channels, however for threads this was never implemented.
This change adds a mention count to the ThreadUnreadsQuery, which is used for channel thread lists and the user thread list. We are also expanding channel mentions count to include mentions within threads.
The goal is to have a more consistent urgent badge across chat, in places such as channel lists and the chat header.
It splits the hide_profile_and_presence user option and the default_hide_profile_and_presence site setting for more granular control. It keeps the option to hide the profile under /u/username/preferences/interface and adds the presence toggle in the quick user menu.
Co-authored-by: Régis Hanol <regis@hanol.fr>
Adds channels with unread threads (watching/tracking) to the sorting logic for both public and direct message channels.
Previously channels with unread threads could easily be missed as we didn't bump them to the top when new thread replies were created.
We are also adding a blue unread badge next to DM channels when there is an unread thread, as previously they weren't appearing as unread within the DMs tab (they only showed within the My Threads section).
`chatThreadPane.isOpened` was returning `false` when it should return `true` due to an incorrect matching on the route.
Note that visiting a thread will focus the composer and the first escape will blur the input, only the second will close the panel.
The markdown it rule "heading" will only be used when the message is done by a bot, which means an id < 0.
This commit also adds a is-bot css class on messages made by a bot, for finer control.
---------
Co-authored-by: Martin Brennan <mjrbrennan@gmail.com>
There's no UI for it at the moment but when creating a channel or updating it, it's now possible to pass `icon_upload_id` as param. This will be available on the channel as `icon_upload_url`.
When adding threads to DM channels in #29170 we intentionally didn't add them to the My Threads section. However this makes it easy to miss notifications as we don't get the new thread badge on the sidebar and footer tabs (drawer/mobile). However they were also missing from the chat header and sidebar too, which is fixed with this PR.
When a new thread or a reply to an existing thread is created within a DM channel (either 1:1 or group), we now show the standard badges like we do for public channels.
We now also show the green dot in the sidebar for My Threads and public channels when they contain an unread watched thread.
This change makes use of service workers to determine if we should play chat sounds in the current browser tab. Since users can have multiple tabs open, we currently attempt to play sound across all active tabs.
With this change we iterate over all clients and check if client.focused is true (ie. the current tab/window we have open), if so we allow playing the audio in the current tab and for all other hidden tabs/windows we return false.
---------
Co-authored-by: Bianca Nenciu <nbianca@users.noreply.github.com>
This API change was unintentionally introduced in 06d32a8a894480673dce31241d81f7aeee50d04e
Partially reverts 23d90ecb26c666e83fd0ec1c19d2f6399f0fd2a7, but keeps the new specs.
In certain locales like English (GB), If a user posted 2 subsequent messages, the first would have a date displayed in 24 hour format, while the second message would be shown in 12 hour format (when hovering the message).
This change forces both messages to display in 12 hour format, the first message showing the am/pm, and the second showing the smaller version without am/pm.
This commit replaces all uppy-related mixins with standalone classes. The main entrypoint is now lib/uppy/uppy-upload.js, which has a list of its config options listed at the top of the file. Functionality & logic is completely unchanged.
The uppy-upload mixin is replaced with a backwards-compatibility shim, which will allow us to migrate to the new pattern incrementally.
