Prior to this commit a long press on the image of a chat message would trigger both the actions menu and the contextual menu. This commit ensures we only show the contextual menu in this case.
No test as it's a quite complex behavior to reproduce (would need android for example).
This was causing this event to cause other touch events down the road. For example click a reaction above the composer when the message action was opened could cause the composer to gain focus after the reaction was made.
It could only occur on message created by the user itself and deleted while the user was looking at the channel.
It more generally fix the trash service which was not correctly setting the author of the delete.
`SiteSetting.enable_public_channels` allows site admin to decide if public channels are available at all. There's no distinction between admins or not as we expect admins to create private category channels if they want to limit usage.
Initial migration and changes to models as well as
changing the following services to update last_message_id:
* Chat::MessageCreator
* Chat::RestoreMessage
* Chat::TrashMessage
The data migration will set the `last_message_id` for all existing
threads and channels in the database.
When we query the thread list as well as the channel,
we look at the last message ID for the following:
* Channel - Sorting DM channels, and channel metadata for the list of channels
* Thread - Last reply details for thread indicators and thread list
It is now safe to render the message excerpt as HTML since
it is no longer using text_entities: true in the server
PrettyText.excerpt call when creating the message excerpt
from the cooked HTML.
This will fix the issue of things like mentions showing
HTML code instead of the actual mention when replying,
and cannot be used to inject improper HTML like style tags
via XSS.
* FEATURE: Inline topic summary. Cached version accessible to everyone.
Anons and non-members of the `custom_summarization_allowed_groups_map` groups can see cached summaries for any accessible topic. After the first 12 hours and if the posts to summarize have changed, allowed users clicking on the button will automatically re-generate it.
* Ensure chat summaries work and prevent model hallucinations when there are no messages.
Browser capabilities are inherently unconnected to the lifecycle of our app. Making them formally available outside of the service means that they can safely be used in non-app-linked functions without needing risky hacks like `helperContext()` or `discourse-common/lib/get-owner`.
One example of where the old hacks were problematic is the `translateModKey()` utility function. This is called in the root of the `discourse/components/modal/keyboard-shortcuts-help` es6 module. If anything (e.g. a theme/plugin) caused that es6 module to be `require()`d before the application was booted, a fatal error would occur.
Following this commit, `translateModKey()` can safely import and access `capabilities` without needing to worry about the app lifecycle.
The only potential downside to this approach is that the capabilities data now persists across tests. If any tests need to 'stub' capabilities, they will need to revert their changes at the end of the test (e.g. by using Sinon to stub a property).
This commit also updates some legacy references from `capabilities:main` to `service:capabilities`.
This implementation will need more work in the future. For simplification of tracking and other events (new thread, delete/restore OM...) we used the threads from `threadsManager` which makes pagination more complicated as we already have some results when we start.
Note this commit also simplify `Collection` to only have one `load` method which can be called repeatedly.
Trying to fix two issues:
1. Sometimes the publish_new! event for update_thread_original_message
finishes running on the UI before the one for thread_created, in this
case we just want to do nothing because thread_created will fetch the
new thread along with its preview from the server if needed
2. Sometimes the thread GET and /read events were erroring because
last_reply on the thread was nil, this was potentially occuring because
the thread_created event was coming through to the UI before the rest
of MessageCreator was done, so we just move that after the big update
to set thread_id for the new and existing messages in the reply
chain
This commit also standardize the naming pattern of modals: `<Chat::Modal::FooBar />` and changes css class accordingly.
Co-authored-by: David Taylor <david@taylorhq.com>
It's way more common to have presence enabled than disabled, so we should have been making it the default from start.
This commit also changes the namespace of `<ChatUserAvatar />` into `<Chat::UserAvatar />` and refactors tests.
Sadly this function is one of the very hard to test codepaths of the app. We could in the future attempt to extract the content of the function to unit-test it.
When a user sends their first message in a thread we
automatically track the thread in the backend, but we
don't reflect this in the UI until the user re-opens
the thread. This commit fixes that by showing the new
tracking level in the UI.
Chat drawer was using the `DiscourseURL` hook `afterRouteComplete`. This hook suffer from a very poor implementation which makes it very unreliable:
```javascript
if (typeof opts.afterRouteComplete === "function") {
schedule("afterRender", opts.afterRouteComplete);
}
```
This commit attempts to return the promise from `handleURL` to directly use it and have a very reliable after transition hook.
In previous changes we prevented creating a channel to also make users follow the channel. We were forcing recipients to follow the channel on message sent but this was not including the creator of the message itself.
This commit fixes it and also write an end-to-end system spec to cover these cases. The message creator service is currently being rewritten and should correctly test and ensure this logic is present.
This commit also makes changes on the frontend to instantly follow a DM when you open it, this change prevents a green dot to appear for a split second when you send a message in a channel you were previously not following. Only recipients will see the green dot.
Followup to 802fb3b194
We should not hide the replies count if there is only 1 participant
for a thread, because this makes it look like the last reply is the
only reply.
This introduces a PLATFORM_KEY_MODIFIER const that
can be used both client and server side, to determine
whether we should be using the Meta or Ctrl key based
on whether the user is on Windows/Linux or Mac.
Why this change?
Before this commit, there is a chance that we will transition the user
to a different route if the chat thread component has been destroyed
prior to the request for fetching messasges in a chat thread returning.
This commit makes it such that we simply ignore the request if the chat
thread component has been destroyed.
We believe this is the cause of the flaky system tests in plugins/chat/spec/system/navigation_spec.rb
which we've been seeing on CI.
This commit includes several fixes and improvements to thread
original message handling:
1. When a thread's original message is deleted, the thread no longer
counts as unread for a user
2. When a thread original message is deleted and the user is looking
at the thread list, it will be removed from the list
3. When a thread original message is restored and the user is looking
at the thread list, it will be added back to the list if it was
previously loaded
In specific conditions (generally a small drawer, with a long message) it is possible to have the message’s actions menu to be displayed hover the drawer's header.
This is particularly hard to fix correctly using popper due to our positioning which is slightly at the limit of the container.
The proposed fix targets mostly the specs by ensuring the messages actions will be hidden before attempting to click any header's button.
- Presence needs to be explicitly set on the component now
- We were not checking and testing correctly the presence of the unread indicator in the menu
This commit replaces two existing screens:
- draft
- channel selection modal
Main features compared to existing solutions
- features are now combined, meaning you can for example create multi users DM
- it will show users with chat disabled
- it shows unread state
- hopefully a better look/feel
- lots of small details and fixes...
Other noticeable fixes
- starting a DM with a user, even from the user card and clicking <kbd>Chat</kbd> will not show a green dot for the target user (or even the channel) until a message is actually sent
- it should almost never do a full page reload anymore
---------
Co-authored-by: Martin Brennan <mjrbrennan@gmail.com>
Co-authored-by: Jordan Vidrine <30537603+jordanvidrine@users.noreply.github.com>
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
* UX: make timestamp font size smaller
* UX: participants use copy instead of avatar
* FIX: Move thread participant count into i18n
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
* DEV: Fix flaky thread nav spec
When we transitioned from the chat thread panel under some conditions
the request for the thread would come back and realise the component
was destroyed, which was trying to do a transition to the channel
itself.
Now we check for the previous route here too and transition to the
correct route.
* DEV: Fix chat transcript spec relying on animation
The on-animation-end modifier is not reliable in system specs
because it fires instantly (we have disabled capybara animations)
so the showCopySuccess boolean can be mutated back to false straight
away.
Better to have a separate boolean tracked with a data-attr that we
can reliably inspect in the system spec.
- Inline mentions on posts
- Inline mentions on chat messages
- The user autocomplete for the composer
- The user autocomplete for chat
- The chat section of the sidebar
This will be used when we move the channel creation for DMs
to happen when we first send a message in a DM channel to avoid
a double-request. For now we can just have a new API endpoint
for creating this that the existing frontend code can use,
that uses the new service pattern.
This also uses the new policy pattern for services where the policy
can be defined in a class so a more dynamic reason for the policy
failing can be sent to the controller.
Co-authored-by: Loïc Guitaut <loic@discourse.org>
Enabling/Disabling threading has been possible through command line until now. This commit introduces two new UIs:
- When creating a channel, it will be available once the category has been selected
- On the settings page of a channel for admins
Addressing TODO about using chatApi in the ChatChannel model,
but since it's a model we cannot easily use the chatApi service.
The model function is only called in one place so we may as well
just move the call there since the component can use chatApi
* FEATURE: Sort thread list by unread threads first
This commit changes the thread list to show the threads that
have unread messages at the top of the list sorted by the
last reply date + time, then all other threads sorted by
last reply date + time.
This also fixes some issues by removing the last_reply
relationship on the thread, which did not work for complex
querying scenarios because its order would be discarded.
* FIX: Various fixes for thread list loading
* Use the channel.threadsManager and find the channel first rather
than use activeChannel in the threads manager, otherwise we may
be looking at differenct channels.
* Look at threadsManager directly instead of storing result for threads
list otherwise it can get out of sync because of replace: true in
other places we are loading threads into the store.
* Fix sorting for thread.last_reply, needed a resort.
Joffrey JAFFEUX
Joe
Martin Brennan
Roman Rizzi
David Taylor
chapoi
Mark VanLandingham
Alan Guo Xiang Tan
Jan Cernik