NOTE: I wasn't able to reproduce locally, so that's my best guess as to what happens based on the production error logs.
It's also the reason why I haven't changed/added any tests...
Earlier today, we started seeing a growing number of errors in the `register_presence_channel_prefix("chat-reply")` handler of the chat plugin.
It was all coming from a Discourse where they make a heavy use of chat channels. They create and **delete** category channels regularly.
If a user has a thread in one of the channels that just got deleted, the client application might not be aware (just yet), asks the server to be connected to the "presence" bus of that channel, and BOOOM.
The following [line](fa0ad0306c/plugins/chat/plugin.rb (L325)) explodes because `chat_channel` is `nil`
```ruby
config.allowed_group_ids = chat_channel.allowed_group_ids
```
And why is `chat_channel` `nil`? Because when we [do](fa0ad0306c/plugins/chat/plugin.rb (L319))
```ruby
chat_channel = Chat::Thread.find_by!(id: thread_id, channel_id: channel_id).channel
```
The thread is still in the database, but the associated channel has been deleted.
A proper fix would most likely be to delete all the `Chat::Thread` associated to a deleted `Chat::Channel` but this might have more technical & business implications.
This update adds a ✨ _new_ `<PostList />` component, along with it's child components (`<PostListItem/>` and `<PostListItemDetails />`). This new generic component can be used to show a list of posts.
It can be used like so:
```js
/**
* A component that renders a list of posts
*
* @component PostList
*
* @args {Array<Object>} posts - The array of post objects to display
* @args {Function} fetchMorePosts - A function that fetches more posts. Must return a Promise that resolves to an array of new posts.
* @args {String} emptyText (optional) - Custom text to display when there are no posts
* @args {String|Array} additionalItemClasses (optional) - Additional classes to add to each post list item
* @args {String} titleAriaLabel (optional) - Custom Aria label for the post title
*
*/
```
```hbs
<PostList
@posts={{this.posts}}
@fetchMorePosts={{this.loadMorePosts}}
@emptyText={{i18n "custom_identifier.empty"}}
@additionalItemClasses="custom-class"
/>
```
* UX: Apply admin table classes for consistent mobile styling on the automation page
* UX: Remove icon beside the automation page title
* DEV: Add status label to translations
* UX: Reorder the status and name when on mobile
* DEV: Add comment explaining tablet-specific status reorder
* DEV: Apply prettier
This converts the `<AdminPageHeader />` component and the
`<AdminPageSubheader />` components into new components
that can be used outside of admin, and updates the CSS classes.
Also introduces a `<DPageActionButton />` component and child
components for the header action buttons.
I have to keep the old admin-only components around for
now until plugins are updated, then we can remove it,
and remove the re-exports that are done within
admin-page-action-button.gjs
We're changing the default of hide_email_address_taken to true. This is a trade-off we want to make, as it prevents account enumeration with minimal impact on legitimate users. If you forget you have an account and try to sign up again with the same e-mail you'll receive an e-mail letting you know.
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 />`
When fetching DM channels, we would fetch all the user's DM channels,
and limit the number of DM channels we display on the client-side using
the `DIRECT_MESSAGE_CHANNELS_LIMIT`.
This is obviously not scalable as users are having more and more
discussions with other users.
This commit ensures we always limit the number of DM channels we send to the
client.
It adds the `MAX_DM_CHANNEL_RESULTS` in `ChannelFetcher` and use it to
limit the records returned by the server. This value should always be
lower than `DIRECT_MESSAGE_CHANNELS_LIMIT` on the client-side, so that
when the user has more "unread DMs" they still show up on the client as
they read them.
While adding a spec, I also updated the spec that ensures we have a
limit on public channels to use `stub_const` to temporarily lower the number
of fixtures we create during the test.
This PR cleans up some unnecessary CSS which are not used anymore. Support of sidebar in chat has a long history due to the various steps leading to the sidebar as we know it today.
Currently, there are two ways (kind of) for accessing `params` inside a
service:
- when there is no contract or it hasn’t been reached yet, `params` is
just the hash that was provided to the service. To access a key, you
have to use the bracket notation `params[:my_key]`.
- when there is a contract and it has been executed successfully,
`params` now references the contract and the attributes are accessible
using methods (`params.my_key`).
This patch unifies how `params` exposes its attributes. Now, even if
there is no contract at all in a service, `params` will expose its
attributes through methods, that way things are more consistent.
This patch also makes sure there is always a `params` object available
even when no `params` key is provided to the service (this allows a
contract to fail because its attributes are blank instead of having the
service raising an error because it doesn’t find `params` in its context).
This patch aims to improve the steps inspector output:
- The service class name is displayed at the top.
- Next to each step is displayed the time it took to run said step.
- Steps that didn’t run are hidden.
- `#inspect` automatically outputs the error when it is present.
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.
Since 3e7f0867ea, I started seeing some specs fail due to the following error
```plain
Error occurred while rendering: top-level application > discourse-root > topic > discourse-topic > topic-navigation > plugin-outlet > plugin-connector > topic-presence-display
/assets/plugins/discourse-presence.js - Uncaught TypeError: Cannot destructure property 'whisperer' of 'this.currentUser' as it is null.
```
For some reasons I can't fanthom, the presence components seem to be rendered even though they're using outlets that are only rendered when a user is signed in... 🤷♂️
Lost too much time trying to reproduce so I ended up adding this `if (!this.currentUser) { return; }` condition to both "presence display" component to (hopefully) fix these flakes.
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.
We've seen in some communities abuse of user profile where bios and other fields are used in malicious ways, such as malware distribution. A common pattern between all the abuse cases we've seen is that the malicious actors tend to have 0 posts and have a low trust level.
To eliminate this abuse vector, or at least make it much less effective, we're making the following changes to user profiles:
1. Anonymous, TL0 and TL1 users cannot see any user profiles for users with 0 posts except for staff users
2. Anonymous and TL0 users can only see profiles of TL1 users and above
Users can always see their own profile, and they can still hide their profiles via the "Hide my public profile" preference. Staff can always see any user's profile.
Internal topic: t/142853.
It's been set to this value as a workaround for long thread titles, but we now have standalone thread titles in the thread body which makes this not needed. People had troubles understanding why they couldn't resize more the thread panel.
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.
In 0993273 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.
Joffrey JAFFEUX
Jordan Vidrine
Jarek Radosz
Régis Hanol
David Taylor
Keegan George
Ella E.
Discourse Translator Bot
Martin Brennan
Isaac Janzen
Ted Johansson
Natalie Tay
Loïc Guitaut
Gerhard Schlager
moin-Jana
Krzysztof Kotlarek
Sérgio Saquetim
David Battersby
Osama Sayegh
Kelv