Prior to this fix if a user had started to reply to a message without actually sending a message, the thread would still be created and we would end up listing it in the threads list of a channel.
This commit also improves adds thread and thread_replies_count to the 4th parameter of the chat_message_created event.
* UX: chat message creator scss cleanup + design tweak to username display
* add user status with live updates to modal
* show user status description in modal
* add tests for user status
* UX: add user-status styling to chat message creator
---------
Co-authored-by: David Battersby <info@davidbattersby.com>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Prior to this fix we were checking if user was not part of a group which allows to chat, but we were not checking if this user was part of groups who can use direct messages.
Prior to this fix clicking <kbd>x</kdb> on a channel row would effectively leave the channel on server side, but it wouldn't disappear from the screen before a page refresh.
With the adjustments of `btn-transparent` in https://github.com/discourse/discourse/pull/24666, there are more buttons that could use this class instead of `btn-flat`. This mostly relates to `x` close buttons, but also includes composer and chat toggles.
The primary difference between these styles is that `btn-transparent` never has a background, where `btn-flat` may have a hover or focus background.
When we send a bookmark reminder, there is an option to delete
the underlying bookmark. The Notification record stays around.
However, if you want to filter your notifications user menu
to only bookmark-based notifications, we were not showing unread
bookmark notifications for deleted bookmarks.
This commit fixes the issue _going forward_ by adding the
bookmarkable_id and bookmarkable_type to the Notification data,
so we can look up the underlying Post/Topic/Chat::Message
for a deleted bookmark and check user access in this way. Then,
it doesn't matter if the bookmark was deleted.
`chat_preferred_mobile_index` allows to set the preferred default tab when loading chat on mobile.
Current choices are:
- channels
- direct_messages
- my_threads
Users can hide their public profile and presence information by checking
“Hide my public profile and presence features” on the
`u/{username}/preferences/interface` page. In that case, we also don't
want to return user status from the server.
This work has been started in https://github.com/discourse/discourse/pull/23946.
The current PR fixes all the remaining places in Core.
Note that the actual fix is quite simple – a5802f484d.
But we had a fair amount of duplication in the code responsible for
the user status serialization, so I had to dry that up first. The refactoring
as well as adding some additional tests is the main part of this PR.
```ruby
ChatSDK::Message.start_stream(message_id: 1, guardian: guardian)
ChatSDK::Message.stream(raw: "foo", message_id: 1, guardian: guardian)
ChatSDK::Message.stream(raw: "bar", message_id: 1, guardian: guardian)
ChatSDK::Message.stop_stream(message_id: 1, guardian: guardian)
```
Generally speaking only admins or owners of the message can interact with a message. Also note, Streaming to an existing message with a different user won't change the initial user of the message.
Prior to this fix, if the last message of a thread had been made by a deleted user it would cause an exception as we would have no user to display, this commit uses a solution we have been using at other places: the null pattern, through the use of `Chat::NullUser.new`.
Plugins can now register this modifier:
```ruby
register_modifier(:chat_can_create_direct_message_channel) do |user, target_users|
# your logic which should return true or false
end
```
Prior to this fix the scroll was ignored when clicking the arrow bottom which would prevent the call to update last read. This fix manually calls update last read in this case and adds a test for it.
In safe mode plugins are not loaded, so the plugin admin
routes are not loaded. This was causing errors in the
admin sidebar because we are trying to show links to the plugin
admin routes.
This fixes the issue by just not adding the plugin links if
we are in safe mode.
If a user had `123456789` as username, it could be passed to the query as a number and the query would fail as it expects a string.
Also applies the same fix to groups.
Why this change?
We noticed that running `LOAD_PLUGINS=1 rspec --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` locally
results in the system tests randomly failing. When we inspected the
request logs closely, we noticed that a `/presence/get` request from a
previous rspec example was being processed when a new rspec example is
already being run. We know it was from the previous rspec example
because inspecting the auth token showed the request using the auth
token of a user from the previous example. However, when a request using
an auth token from a previous example is used it ends up logging out the
same user on the server side because the user id in the cookie is the same
due to the use of `fab!`.
I did some research and there is apparently no way to wait until all
inflight requests by the browser has completed through capybara or
selenium. Therefore, we will add an identifier by attaching a cookie to all non-xhr requests so that
xhr requests which are triggered subsequently will contain the cookie in the request.
In the `BlockRequestsMiddleware` middleware, we will then reject any
requests when the value of the identifier in the cookie does not match the current rspec's example
location.
To see the problem locally, change `Auth::DefaultCurrentUserProvider.find_v1_auth_cookie` to the following:
```
def self.find_v1_auth_cookie(env)
return env[DECRYPTED_AUTH_COOKIE] if env.key?(DECRYPTED_AUTH_COOKIE)
env[DECRYPTED_AUTH_COOKIE] = begin
request = ActionDispatch::Request.new(env)
cookie = request.cookies[TOKEN_COOKIE]
# don't even initialize a cookie jar if we don't have a cookie at all
if cookie&.valid_encoding? && cookie.present?
puts "#{env["REQUEST_PATH"]} #{request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access}"
request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access
end
end
end
```
After which run the following command: `LOAD_PLUGINS=1 rspec --format documentation --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb`
It takes a few tries but the last spec should fail and you should see something like this:
```
assets/chunk.c16f6ba8b6824baa47ac.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/assets/chunk.050148142e1d2dc992dd.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/chat/api/channels/527/messages {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/uploads/default/test_0/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_512x512.png {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
redirects to existing chat channel
redirects to chat channel if recipients param is missing (PENDING: Temporarily skipped with xit)
with multiple users
/favicon.ico {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736}
/chat/new-message {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736}
/presence/get {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
```
Note how the `/presence/get` request is using a token from the previous example.
Co-authored-by: David Taylor <david@taylorhq.com>
We have separated and combined modes for sidebar panels.
Separated means the panels show only their own sections,
combined means sections from all panels are shown.
The admin sidebar only shows its own panels, so it must set
the mode to separated; however when we navigate to chat or
home we must revert to the initial mode setttings.
When hiding/showing the sidebar, as is the case on mobile
and using the toggle in the top left on desktop, we delete
and recreate the ember component on the page. This causes
the `sections` for each sidebar panel to get re-evaluated
every time.
For the admin sidebar, this means that we were constantly
re-adding the plugin links to the sidebar, causing duplication.
This can be fixed by just adding @cached to the getter for
sections.
This feature adds the functionality to start a new chat directly from the URL using query params.
The format is: /chat/new-message?recipients=buford,jona
The initial version of this feature allows for the following:
- Open an existing direct message channel with a single user
- Create a new direct message channel with a single user (and auto redirect)
- Create or open a channel with multiple users (and auto redirect)
- Redirects to chat home if the recipients param is missing
This commit introduces the possibility to stream messages. To allow plugins to use streaming this commit also ships a `ChatSDK` library to allow to interact with few parts of discourse chat.
```ruby
ChatSDK::Message.create_with_stream(raw: "test") do |helper|
5.times do |i|
is_streaming = helper.stream(raw: "more #{i}")
next if !is_streaming
sleep 2
end
end
```
This commit also introduces all the frontend parts:
- messages can now be marked as streaming
- when streaming their content will be updated when a new content is appended
- a special UI will be showing (a blinking indicator)
- a cancel button allows the user to stop the streaming, when cancelled `helper.stream(...)` will return `false`, and the plugin can decide exit early
Affects the following settings:
delete_all_posts_and_topics_allowed_groups
experimental_new_new_view_groups
enable_experimental_admin_ui_groups
custom_summarization_allowed_groups
pm_tags_allowed_for_groups
chat_allowed_groups
direct_message_enabled_groups
chat_message_flag_allowed_groups
This turns off client: true for these group-based settings,
because there is no guarantee that the current user gets all
their group memberships serialized to the client. Better to check
server-side first.
Why this change?
The tests are consistently flaky and failing with the following error:
```
CapybaraTimeoutExtension::CapybaraTimedOut:
This spec passed, but capybara waited for the full wait duration (10s) at least once. This will slow down the test suite. Beware of negating the result of selenium's RSpec matchers.
```
In certain cases, chat channels may have empty slugs, it happens when:
1. The `slug_generation_method` setting is set to `None`
2. `slug_generation_method` is set to `ASCII` and a channel with
a Unicode name and an empty slug is created (in this case, the code
that creates channels tries to generate a slug and fallbacks to an empty slug)
At the moment, we have a unique index on the `chat_channels.slug` column
which leads to errors when creating several channels with empty slugs
(Discourse is able to create one such channel, but when trying to create
the second one fails because of the unique constraint). This PR fixes that
by adding a `where` condition to the index. Slugs still have to be unique,
but now many channels may have empty slugs.
This fix is similar to the one we made to the category slugs – 7ba914f1e1.
This commit was created with a combination of the ember-native-class-codemod and manual cleanup.
User-status-related functionality was previously encapsulated in its own `User.reopen` call, which is essentially an 'inline mixin'. This commit refactors it into a utility class, with an instance accessible on `User#statusManager`
The service `Chat::CreateMessage` will now accept `context_post_ids` and `context_topic_id` as params. These values represent the topic which might be visible when sending a message (for now, this is only possible when using the drawer).
The `DiscourseEvent` `chat_message_created` will now have the following signature:
```ruby
on(:chat_message_created) do | message, channel, user, meta|
p meta[:context][:post_ids]
end
```
Channels can include emojis in front of the channel title which causes problems when sorting.
Using the channel slug is a more reliable way to sort and avoid these kind of issues.
This change will sort channels by activity on mobile, with preference to those with urgent or unread messages.
Channels with mentions will appear first, followed by channels with unread messages, then finally everything else sorted by the channel title (alphabetically).
This commit includes several changes to make hashtags work when "lazy
load categories" is enabled. The previous hashtag implementation use the
category colors CSS variables, but these are not defined when the site
setting is enabled because categories are no longer preloaded.
This commit implements two fundamental changes:
1. load colors together with the other hashtag information
2. load cooked hashtag data asynchronously
The first change is implemented by adding "colors" to the HashtagItem
model. It is a list because two colors are returned for subcategories:
the color of the parent category and subcategory.
The second change is implemented on the server-side in a new route
/hashtags/by-ids and on the client side by loading previously unseen
hashtags, generating the CSS on the fly and injecting it into the page.
There have been minimal changes outside of these two fundamental ones,
but a refactoring will be coming soon to reuse as much of the code
and maybe favor use of `style` rather than injecting CSS into the page,
which can lead to page rerenders and indefinite grow of the styles.
When we show the links to installed plugins in the admin
sidebar (for plugins that have custom admin routes) we were
previously only doing this if you opened /admin, not if you
navigated there from the main forum. We should just always
preload this data if the user is admin.
This commit also changes `admin_sidebar_enabled_groups` to
not be sent to the client as part of ongoing efforts to
not check groups on the client, since not all a user's groups
may be serialized.
The leave channel button is cut off when accessing the channel settings page on mobile.
This change adds additional padding to the bottom of the channel settings page when accessing via iPad/PWA/Hub.
Chat mobile has separate routes for channels and direct messages. However on desktop we want to prevent these routes from being accessible as they aren't intended to be used by chat in full-page or drawer mode on desktop.
We had two issues which were present for a long time I think:
- one that impacts both core discourse and chat. We were not setting top on the header when `footer-nav-ipad` was present, meaning that you could make it scroll under if you try to scroll up by putting your finger on the discourse header
- one that impacted only chat. It's also present in core, but in core it's not a probem because we don't have a fixed height div. The body height was higher than the screen which would cause a second scrollbar to appear and would slightly break layout, if you scroll on this scrollbar (body).
* UX: increase font-size of last message + decrease emoji size
* UX: decrease size of username emoji
* UX: Mobile chat index cleanup
* UX: decrease size of chat-channel-title in thead list
Chat should follow the same convention as topics, where invalid mentions
are not styled the same as valid mentions. This PR makes chat use such styling.
I'm following the same pattern that we use for invalid mentions in posts –
9bd6523581/app/assets/stylesheets/common/base/topic-post.scss (L1285-L1288)
This way it'll be easier to dry it up if we decide to do that at some point.
We've changed access settings to be group membership based rather than based on the TL value directly. We kept both conditions here while we updated any plugins and themes. It should now be safe to remove.
This commit adds a link to the original message of a thread, this link will:
- load the channel message and highlight it while keeping thread panel open on desktop
- open the channel and highlight the message in mobile (and close thread panel, as mobile never shows channel and thread in the same view)
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
Since https://github.com/discourse/discourse/pull/25501 this behavior was broken. This PR attempts to fix it by being more fine grain.
Also note that this PR is moving `footer-nav-ipad` and `footer-nav-visible` to the `html` element and not the `body`. It makes more sense as we are already adding most of other global state class like `keyboard-visible` to the `html` element.
Tested on:
- chrome desktop
- safari ios - iphone
- PWA ios - iphone
- PWA ios - ipad
- DiscourseHub iphone
This commit sets a default of 0px for `--footer-nav-height` and set it only when `body.footer-nav-visible` allowing us to safely use `--footer-nav-height` wherever it will be needed if set.
We usually don't enforce foreign key relationships on the database level.
Because of that, occasionally it's possible to see a chat message that
references to a non-existent chat_channel or user. MessagesExporter
failed in such case before, this PR fixes that.
When reaching the top of a thread, the full thread title will be displayed if it was too long to fit.
It works in mobile, drawer mode, and fullscreen.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
For performance reasons we don't automatically add fabricated users to trust level auto-groups. However, when explicitly passing a trust level to the fabricator, in 99% of cases it means that trust level is relevant for the test, and we need the groups.
This change makes it so that when a trust level is explicitly passed to the fabricator, the auto-groups are refreshed. There's no longer a need to also pass refresh_auto_groups: true, which means clearer tests, fewer mistakes, and less confusion.
This change adds notification badges to the new footer tabs on mobile chat, to help users easily find areas where there’s new activity to review.
When on mobile chat:
- Show a badge on the DMs footer when there is unread activity in DMs.
- Show a badge on the Channels footer tab when there is unread channel activity.
- Show a badge on the Threads footer tab when there is unread activity in a followed thread.
- Notification badges should be removed once the unread activity is viewed.
Additionally this change will:
- Show green notification badges for channel mentions or DMs
- Show blue notification badges for unread messages in channels or threads
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
The value [Yesterday] was a fixed string which couldn't be translated. Also removes nextWeek/nextDay which make no sense for dates which are always supposed to be in the past.
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_to_tag_topics site setting to tag_topic_allowed_groups.
We have all these calls to Group.refresh_automatic_groups! littered throughout the tests. Including tests that are seemingly unrelated to groups. This is because automatic group memberships aren't fabricated when making a vanilla user. There are two places where you'd want to use this:
You have fabricated a user that needs a certain trust level (which is now based on group membership.)
You need the system user to have a certain trust level.
In the first case, we can pass refresh_auto_groups: true to the fabricator instead. This is a more lightweight operation that only considers a single user, instead of all users in all groups.
The second case is no longer a thing after #25400.
Having the admin sidebar code in an instance initializer is not
ideal because:
* It runs during app boot which may not even be necessary based on site settings
* It makes it hard for plugins to register additional links in time without resorting
to before/after initializer gymnastics
This PR moves the admin sidebar into a lib and creates the panel
in custom-sections.js, then the sections and links are loaded when
the main sidebar component is rendered, which leaves plugins enough
time to add additional links in an initializer.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
Fixes an issue with delayed rendering of the My Threads tab in chat mobile footer.
Previously we made an ajax request to determine the number of threads a user had before rendering the tab, however it is much faster (and better UX) if we can rely on a site setting for this.
The new chat_threads_enabled site setting is set to true when the site has chat channels with threading enabled.
This bug was causing broken layout when using the `header_dropdown` setting instead of `sidebar` as we were rendering `<div class="channels-list"></div>` two times.
In normal use, this `text()` getter is never called. However, when running with the Ember inspector, it is eagerly evaluated and hits throws the "not implemented" error in the base class.
* FIX: Minor bookmark issues
* We were showing "missing %{name} value" when the name for the
bookmark was undefined with title translations
* There was no way to see the bookmark details on hover in chat
for a message where the bookmark icon was in the left gutter.
We can show the title on the bookmark button in the chat message
actions instead.
* Minor fix
* DEV: Test fix
Due to an incorrect test the previous service was incorrectly implementing the map, and was most importantly not deleting the state when reaching bottom.
It was broken on iOS PWA, when you had the keyboard open and would leave the app. When you came back the body was scrolled and it was looking buggy until you close/reopen keyboard.
This commit attempt to reposition the page correctly 200ms after the tab is visible again.
This commit creates a shared implementation of the dates computation and moves all the logic (new messages since last visit and dates separator into one single component <ChatMessageSeparator />).
The frontend tests have been removed and only a single system spec has been added for threads as everything is sharing the same implementation and the existing channel specs should catch any regression.
Allows users to create DMs by selecting groups as a target. It also allows adding user groups to an existing chat
- When creating the channel, it expands the user group and adds all its members with chat enabled to the channel.
- After creation, there's no difference between adding a group or adding its members individually.
- Users can add multiple groups and users simultaneously.
- There are UI validations; the member count preview updates according to the member count of added groups, and it does not allow users to add more members than SiteSetting.chat_max_direct_message_users."
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
This change moves the "Channels" tab to first position in the chat footer nav, and loads it as the default page when opening chat for the first time on mobile.
This update adds three tabs to the bottom of the chat overlay to make it easier for users to navigate chat on mobile.
As a result of this change:
- Direct Messages are now shown separately from public channels on mobile
- My Threads has now moved from the channel list to it's own tab on mobile
- My Threads can still be accessed on desktop via the sidebar and within the drawer channel list
- Chat back button has been updated to navigate to the correct tab (for both channels and threads)
Some special cases:
- If DMs are not used then the tab is not rendered
- If the user has no threads then the tab is not rendered
- If both the tabs for DMs and Threads aren't available then the whole footer will not be rendered
- Chat footer is only shown on the listing pages (DMs, Channels, My Threads)
---------
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_to_tag_topics site setting to tag_topic_allowed_groups.
This commit:
- increased the size of chat-header-offset from 46px to 56px on mobile
- tweaked navbar padding
- Increased the gap between back button and title; this means no more perfect alignment, but I think that's perfectly fine and a fair trade off for an easier click target for the back button without fear of hitting the title
This regressed in 2791e75072. That commit
fixed subfolder URLs in general, but the `full_url` was adding the
subfolder prefix a second time, thus breaking this URL in emails.
Prior to this fix the number of users rendered by mentioned_users could equal the number of members in a channel which would be slow but could in more extreme case crash the page and/or server.
Some plugins have names (e.g. discourse-x-yz) that
are totally different from what they are actually called,
and that causes issues when showing them in a sorted way
in the admin plugin list.
Now, we should use the setting category name from client.en.yml
if it exists, otherwise fall back to the name, for sorting.
This is what we do on the client to determine what text to
show for the plugin name as well.
This adds the following chat metrics:
- _chat_open_channels_with_threads_enabled_ — a count of open channels
where threading is enabled.
- _chat_channel_messages_ — a count of messages sent in a chat channel
(i.e. not a personal chat / direct message), within a thread or outside of a thread.
- _chat_threaded_messages_ — a count of messages sent within a thread
in a chat channel (i.e. not a personal chat / direct messages).
- _chat_direct_messages_ — a count of messages sent in a personal chat / direct messages.
The metrics added using the plugin API introduced in 098ab29d,
and extended in d91456fd.
Note that these stats won't be exposed at the `about.json`
and the `site/statistics.json` routes.
Joffrey JAFFEUX
chapoi
Discourse Translator Bot
David Taylor
Mark VanLandingham
Loïc Guitaut
Jarek Radosz
Kris
David Battersby
Martin Brennan
Isaac Janzen
Andrei Prigorshnev
Alan Guo Xiang Tan
Jan Cernik
Krzysztof Kotlarek
Bianca Nenciu
Ted Johansson
Selase Krakani
Penar Musaraj