When clicking the "new features" notification item for
admins that navigates to /whats-new, the user notification
menu was not closing. This was happening because inside
the UserMenu::Menu component, the `routeDidChange` event
was firing and calling `closeUserMenu()`, however this is already
called inside the `Header` component via `toggleHamburger()`.
This is _only_ happening for the "new features" notification
item, other items have already been destroyed and they do not get
the `routeDidChange` event. No idea why, but this fixes the issue
in a global way.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/(lib|utils)/*` into
`discourse/lib/*`, adds shims for the imports, and updates existing
uses in core.
And change the "formula" to check for duplicate messages to
- no duplicate check in 1:1 DMs
- only duplicate check in group DMs / channels, for posts made by the
same user, in the past 10 seconds
Internal ref - t/144262
This will have the following advantages:
- removes a very annoying bug which was making text selection super hard on iOS
- removes the flashing of header when transitioning from disable to enable body scroll lock
- uses emojiSearch to ensure we have the same result than autocomplete when filtering emojis (for example search aliases were not working correctly because of this)
- reset the visible sections when clearing filter to ensure we are not attempting to display all the emojis at once which would be slow
- prevents flashing of the full emoji list before showing filtered results
- correctly reset recent favorites and only show them when used
Now that we correctly await for the modal to close, we dont need to special case and disable focusTrigger, the flow will now be:
- click an element of the menu
- wait for modal to close
- focus trigger
- trigger action, which will eventually open a modal and attempt to focus the first item
The chat emoji picker is renamed emoji-picker, and the old emoji-picker is removed.
This commit doesn't attempt to fully rework a new emoji-picker but instead tries to migrate everything to one picker (the chat one) and add small changes.
Other notable changes:
- all the favorite emojis code has been mixed into one service which is able to store one state per context, favorites emojis will be stored for all topics, and for each chat channel. Meaning that if you always use a specific emoji in a channel, it will only show as favorite emoji in this channel.
- a lot of static code has been removed which should improve initial load perf of discourse. Initially this code was around to improve the performance of the emoji picker rendering.
- the emojis are now stored, once the full list has been loaded, if you close and reopen the picker it won't have to load them again.
List of components:
- `<EmojiPicker />` will render a button which will open a dropdown
- `<EmojiPickerContent />` represents the content of the dropdown alone, it's useful when you want to render a picker from an action which is not the default picker button
- `<EmojiPickerDetached />` just a simple wrapper over `<EmojiPickerContent />` to make it easier to use it with `this.menu.show(...)`
---------
Co-authored-by: Renato Atilio <renatoat@gmail.com>
This test is flaky, sometimes it fails with the hamburger menu blocking the click on the emoji, other times it just doesn't return the list of emojis when the search term is there.
Other similar emoji tests are skipped. Stopping the bleed, but we still need to figure out a more reliable testing strategy here.
Will revisit after #28277 is merged.
ref /t/-/145212
When inserting anything from the chat composer dropdown, any popups opened weren't properly focussed.
This was due to the default behaviour of the dropdown menu closing, which tries to return the focus to the original triggering element. This would normally be the correct behaviour, but here we want the menu to close in the background, handing focus off to the popup, instead.
* UX: Admin setting page consistency - Group permissions (#30528)
Followup c2282439b32d879a73217eec62449f042914d7d0 and
21470e4afd49127fc6281a5bde6357e86b11a4ae
Adds a new "Group permissions" page and group_permissions site
setting area, which shows every single group-based site setting
in the app and core plugins.
Also adds a "trust_levels" area to show on the already moved
admin "Trust level" settings page, since that previously was
showing a mix of trust level settings and allowed group settings.
* DEV: Review fixes
The `faker` gem, which is a dependency for the `*:populate` rake tasks, isn't installed in the production environment, so we should only load files/classes related to those rake tasks in non-production environments.
Related to 5a55c9062a
The chat plugin now makes use of the plugin API that was added in the linked commit for extending the reviewables:populate rake task.
For mentions within threads, the mentioned user can experience a stuck notification. This is due to thread memberships only being created for users who interact with a thread. Without the membership we cannot track if the message containing the mention was read by the user.
The solution to this explored in this PR is:
- auto add memberships for mentioned users (only direct mentions for performance reasons).
- update channel/thread unread queries to check notification read status AND thread membership last read message id when counting mentions.
Previously the mention count would remain until the user notification (containing the mention) was read. However this only happens if the user clicks the notification or clicks dismiss all notifications. When a user navigated to the thread without clicking the notification, the green/urgent badge on chat would remain even after a hard page refresh.
Create a basic config page that only contains navigation-related settings, to replace the setting filtered view linked to from "Navigation" in the admin sidebar.
Followup c2282439b32d879a73217eec62449f042914d7d0
Make the Notifications config page reached from the sidebar
use our consistent site setting page rules.
After searching for an emoji through the autocomplete, when a user uses the emoji picker (to see the full list of emojis) and selects one, the content in the chat composer would contain both the partially written emoji and the full :selected_emoji: code.
The actual fix is just re-using the emojiSelected method from TextManipulation.
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 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
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.
