Why this change?
`Faker::Lorem.paragraph` generates a differrent length of string
every time. When a string happens to be long, it can change the UI
across system test runs making it harder to reason about our system
tests across multiple runs since the state is never really consistent.
We will just generate a paragraph with a fixed length going forward so
that the UI remains consistent. This should make certain tests which
relies on the UI being in a certain state to become less flaky.
Why this change?
This change ensures that we scroll to the top of the message when
hovering over a message to ensure that the message actions container
that appears on hover is not hidden in the chat drawer when the content
of the chat message is long.
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.
Why this change?
In CI, we know we're clicking a link to a chat channel's threads list.
However, the threads list is not loaded and we want to add more
assertions here to try and figure out why. By asserting for the current
URL, we will at least know that the transition to the URL is successful.
- 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>
Without this fix, the following error is raised:
```
ActiveRecord::StatementInvalid:
PG::SyntaxError: ERROR: syntax error at or near ")"
LINE 4: WHERE thread_id IN ()
```
Why this change?
Chat system tests that opens the message actions on mobile have been
flaky on our CI. Those system test usually fails when the message
actions do not show up as expected causing subsequent actions to fail.
In the case of the `Reply to message - channel - mobile when the message has an existing thread replies to the existing thread`
system test, failure screenshot shows that we ended up navigating to the
thread instead of opening the message actions button. To understand why
this happens, we first need to understand that by default Capybara clicks
on the centre of an element. Also, we need to note that the HTML structure of
a chat message is like so:
```
<div class="chat-message-container">
<div class="chat-message">
<div class="chat-message-avatar" />
<div class="chat-message-content" />
<div class="chat-message-thread-indicator" />
</div>
</div>
```
Since `PageObjects::Pages::ChatChannel#expand_message_actions_mobile`
attempts to click on the `.chat-message-contaier`, there is a
possibility that the center of that element is the
`.chat-message-thread-indicator` element which would explain why we
navigated to the thread list instead of opening up the message actions.
This is possible because the content of the original chat message as
well as the message excerpt in the thread is randomly generated where the
length of the message and how the text wraps on mobile can affect the
height of the `.chat-message-content` element as thus its position in
the `.chat-message-container` element. In most cases, the middle of the
`.chat-message-container` happens to be the `.chat-message-content`
which is why this test "flakes" sometimes.
What is the solution?
Instead of clicking on the `.chat-message-container`, we be more
specific and click on the `.chat-message-content` element instead.
* 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.
Why this change?
By ensuring the reset happens in an `ensure` code block, we ensure that
the code will always be run even if code fails or an error is raised.
This helps to prevent leaking custom network condition states and
improves the stability of our system tests.
- 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 fixes a longstanding TODO to move the contents of the
UpdateUserCountsForChannels job to the ensure_consistency!
method of Chat::Channel, which runs every 15 mins as part of
periodical updates.
This commit also addresses the performance issue of the original,
where we would fetch all channels and do an individual query to
get the count and update the count of each one. Now we do it all
in one query, and only publish the changed channels to the UI.
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>
This has been flagged by our internal system as well and has been
failing on CI. Skip this for now to improve the stability of our system
test runs while we figure out why it is flaky.
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
Whenever a user opens a channel or marks it read, we now
update the last_viewed_at datetime for that channel membership
record. This is so we will be able to show thread unread indicators
in the channel sidebar that clear independently of the main thread
unread indicators. This unread functionality will follow in another
PR.
Followup to c6b43ce68b
We can just use the rich excerpt everywhere since we know
we don't need text_entities -- that introduced security issues
just to fix a spec.
Introduced in cec68b3e2c,
this is flaky because if you click the back button before
the route is fully transitioned to the loaded thread,
we end up going to the history _before_ the thread list,
which ends up being the channel.
We need to make sure that everything is loaded for the
thread first, meaning the skeleton is not there.
Also exclude some noise from the capybara logs (image load failures)
Followup to 1526d1f97d
This commit fixes an N1 for mentions/user status
when querying chat threads. This only happened if
any of the thread OMs had mentions.
* 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.
When clicking back from a thread, we want to either go back to the
channel if the thread was opened from an indicator, or to the thread
list if we opened it from there. Since ember doesn't give a nice way
to get the previous route, we need to store this ourselves. We only
do this on mobile, on desktop we just follow existing behaviour.
Also implements a chat router history.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Updates the interface for implementing summarization strategies and adds a cache layer to summarize topics once.
The cache stores the final summary and each chunk used to build it, which will be useful when we have to extend or rebuild it.
This small patch registers a new `ActiveModel` type: `array`.
It will split a string on `,` to create a new array. If the value is
already an array, nothing will happen and for all other types, it will
wrap the value in an array.
Here’s an example on an existing contract:
```ruby
attribute :target_usernames
before_validation do
self.target_usernames =
(
if target_usernames.is_a?(String)
target_usernames.split(",")
else
target_usernames
end
)
end
# can be rewritten as:
attribute :target_usernames, :array
```
To export chat messages, go to `/admin/plugins/chat` and click the Create export
button in the _Export chat messages_ section. You'll receive a direct message
when the export is finished.
Currently, this exports all messages from the last 6 months, but not more than
10000 messages.
This exports all chat messages, including messages from private channels and
users' direct conversations. This also exports messages that were deleted.
This PR adds a new parameter to fetch chat messages: `target_date`.
It can be used to fetch messages by a specific date string. Note that it does not need to be the `created_at` date of an existing message, it can be any date. Similar to `target_message_id`, it retrieves an array of past and future messages following the query limits.
This commit adds an aria-label attribute to cooked hashtags using
the post/chat message decorateCooked functionality. I have just used
the inner content of the hashtag (the tag/category/channel name) for
the label -- we can reexamine at some point if we want something
different like "Link to dev category" or something, but from what I
can tell things like Twitter don't even have aria-labels for hashtags
so the text would be read out directly.
This commit also refactors any ruby specs checking the HTML of hashtags
to use rspec-html-matchers which is far clearer than having to maintain
the HTML structure in a HEREDOC for comparison, and gives better spec
failures.
c.f. https://meta.discourse.org/t/hashtags-are-getting-a-makeover/248866/23?u=martin
https://meta.discourse.org/t/markdown-preview-and-result-differ/263878
The result of this markdown had different results in the composer preview and the post. This is solved by updating Loofah to the latest version and using html5 fragments like our user had reported. While the change was only needed in cooked_post_processor.rb for this fix, other areas also had to be updated due to various side effects.
- Moves `<ChatMessageInfo />` to `<Chat::Message::Info />`
- Moves `<ChatMessageAvatar />` to `<Chat::Message::Avatar />`
- Moves `<ChatMessageLeftGutter />` to `<Chat::Message::LeftGutter />`, adds tests
- Creates `<Chat::Message::Error />`
- Creates `<Chat::Message::MentionWarning />`, adds tests and a styleguide
- Creates a model for ChatMessageMentionWarning, adds fabricator for it
- Keeps the enter/leave viewport logic inside the `<ChatMessage />` component instead of bubbling it to the channel and thread components
- Adds a scale animation when clicking a reaction
- Creates `chat/later-fn` modifier which accepts a function and a delay. It allows to call a function Xms after a component has been inserted, it's useful for animations.
- Moves css code out of chat-message into relevant files
- Deletes unused code
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
- FIX: improves reactions and thread indicator touch event on mobile
These "buttons" are located inside a scroll list which makes them very specific. The general idea is to ensure these events are passive and are not bubbling to the parent.
- DEV: moves state on top level message node
- FIX: ensures popover arrow has the correct border
- FIX: makes a message expanded by default
- FIX applies the same ios scroll fix on thread and channel
- UI: better active/hover state for thread indicator
- UI: attempts to follow more closely our BEM naming scheme
- FIX: reduces bottom padding on message with thread indicator and user info hidden
- UI: add padding for first message in thread
- FIX: prevents actions backdrop to open thread
- UI: makes thread indicator resizable
This method is a huge footgun in production, since it calls
the Redis KEYS command. From the Redis documentation at
https://redis.io/commands/keys/:
> Warning: consider KEYS as a command that should only be used in
production environments with extreme care. It may ruin performance when
it is executed against large databases. This command is intended for
debugging and special operations, such as changing your keyspace layout.
Don't use KEYS in your regular application code.
Since we were only using `delete_prefixed` in specs (now that we
removed the usage in production in 24ec06ff85)
we can remove this and instead rely on `use_redis_snapshotting` on the
particular tests that need this kind of clearing functionality.
This commit adds a tracking dropdown to each individual thread, similar to topics,
that allows the user to change the notification level for a thread manually. Previously
the user had to reply to a thread to track it and see unread indicators.
Since the user can now manually track threads, the thread index has also been changed
to only show threads that the user is a member of, rather than threads that they had sent
messages in.
Unread indicators also respect the notification level -- Normal level thread tracking
will not show unread indicators in the UI when new messages are sent in the thread.
The events leading to this mistake are unclear but we decided few months ago to make direct messages NOT flaggable and even wrote a spec for this, when we actually support flagging of direct messages.
This commit ensures it will show for direct messages channels and inverses the existing spec.
This commit fixes the selection of message in threads and also applies various refactorings
- improves specs and especially page objects/components
- makes the channel/thread panes responsible of the state
- adds an animationend modifier
- continues to follow the logic of "state" should be displayed as data attributes on component by having a new `data-selected` attribute on chat messages
This commit adds the initial part of thread indicator improvements:
* Show the reply count, last reply date and excerpt,
and the participants of the thread's avatars and
count of additional participants
* Add a participants component for the thread that
can be reused for the list
* Add a query class to get the thread participants
* Live update the thread indicator more consistently
with the last reply and participant details
image image
In subsequent PRs we will cache the participants since
they do not change often, and improve the thread list
further with participants.
This commit also adds a showPresence boolean (default
true) to ChatUserAvatar, since we don't want to show the
online indicator for thread participants.
---------
Co-authored-by: chapoi <charlie@discourse.org>
* FEATURE: Content custom summarization strategies.
This PR establishes a pattern for plugins to register alternative ways of summarizing content by extending a class that defines an interface.
Core controls which strategy we'll use and who has access to it through the `summarization_strategy` and `custom_summarization_allowed_groups`. It also defines the UI for summarizing topics.
Other plugins can access this summarization mechanism and implement their features, removing cross-plugin customizations, as it currently happens between chat and the discourse-ai plugin.
* Group membership validation and rate limiting
* Work with objects instead of classes
* Port summarization feature from discourse-ai to chat
* Rename available summaries to 'Top Replies' and 'Summary'
* move the chat unread indicator to top to match the profile avatar indicator
* add white border to profile avatar indicator (badge notification) to match chat indicator and userstatus styling
* change `.urgent` to BEM
* congregate all styling into mixin
* update chat index to use mixin
* update thread indicator to use mixin
* update header indicator to use mixin
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Martin Brennan <martin@discourse.org>
Currently navigating a long topic and then opening chat would cause the view to be scrolled to the bottom. Using `scrollTop` here ensures we correctly scroll to top.
This had been incorrectly moved into `deactivate` during another change.
* FIX: increases resize observer throttle delay
25ms is not necessary and was sometimes causing jankyness.
* FIX: removes ios momentum fix delay
Instead of a 50ms, simply use next+schedule("afterRender") to attempt to have the shortest delay possible.
* FIX: backdrop event propagation
Prevents backdrop touch to propagate to underlying channel/thread.
* UX: adds is-active class to container of active message
This change allows to keep the background on the active message while the actions menu is displayed.
* FIX: prevents skip-link to be selected on press
* UX: allows to close actions menu instantly
The backdrop should always receive events, we don't need to wait for the menu to be fully displayed.
* UI: adds spacing between last message and composer
* UI: makes backdrop less dark
* FIX: makes events passive on long-press modifier
This commit attempts to have a bullet proof solution to the following case:
- long press on message (finger is still pressed)
- menu appears
- a button is now at finger location
- user releases finger
- a click is triggered on the button
Classic event canceling solution won't work here for performance reasons as we need the event to be passive in a scroll list.
This fixes an issue where a user could send an empty
string as a chat message .e.g ' ' and the message would
be posted. We don't want this, we need to strip the message
first before validating for length etc.
This commit contains multiple changes to improve the composer behavior especially in the context of a thread:
- Generally rename anything of the form `chatChannelThread...` to `chatThread...``
- Moves the textarea interactor instance inside the composer server
- Improves the focus state and closing of panel related to the use of the Escape shortcut
- Creates `Chat::ThreadList` as a component instead of having `Chat::Thread::ListItem` and others which could imply they were children of a the `Chat::Thread` component
One user can create a post or chat message with a hashtag they
have permission to use, but then when other users look at that
post they will see an empty space next to the hashtag because they
do not have the permission to load the colors in CSS classes for
the related category.
This fixes the issue by adding a default color with a special
CSS class if the user doesn't have permission to see the linked
channel/category on the hashtag.
What is the problem?
We were calling out to methods that calls `has_css?` or `has_selector?`
which returns a boolean. Since we are not using the return value, it
means the methods can be deemed unnecessary. However, we do want those
checks and this commit adds the necessarily assertions to make use of
the return values.
This reverts commit ddf4ecba04.
Causing a flaky test to appear:
```
main $ LOAD_PLUGINS=1 rspec plugins/chat/spec/system/chat/composer/shortcuts/channel_spec.rb
Randomized with seed 17765
.....F..
Failures:
1) Chat | composer | shortcuts | channel when using ArrowUp when last message is staged does not edit a message
Failure/Error: channel_page.send_message
expected `#<PageObjects::Components::Chat::Messages:0x00007fe823ac1710 @context=".chat-channel">.has_message?({:persisted=>true, :text=>"2"})` to be truthy, got false
[Screenshot Image]: /home/tgxworld/work/discourse/tmp/capybara/failures_r_spec_example_groups_chat_composer_shortcuts_channel_when_using_arrow_up_when_last_message_is_staged_does_not_edit_a_message_148.png
```
What is the problem?
We were calling out to methods that calls `has_css?` or `has_selector?`
which returns a boolean. Since we are not using the return value, it
means the methods can be deemed unnecessary. However, we do want those
checks and this commit adds the necessarily assertions to make use of
the return values.
If we're asserting that something is missing, we want to use
`has_no_css?` instead of `!has_css?` since `has_css?` will wait the full
capybara default wait time before return if the selector is not present.
* FEATURE: reduce avatar sizes to 6 from 20
This PR introduces 3 changes:
1. SiteSetting.avatar_sizes, now does what is says on the tin.
previously it would introduce a large number of extra sizes, to allow for
various DPIs. Instead we now trust the admin with the size list.
2. When `avatar_sizes` changes, we ensure consistency and remove resized
avatars that are not longer allowed per site setting. This happens on the
12 hourly job and limited out of the box to 20k cleanups per cycle, given
this may reach out to AWS 20k times to remove things.
3.Our default avatar sizes are now "24|48|72|96|144|288" these sizes were
very specifically picked to limit amount of bluriness introduced by webkit.
Our avatars are already blurry due to 1px border, so this corrects old blur.
This change heavily reduces storage required by forums which simplifies
site moves and more.
Co-authored-by: David Taylor <david@taylorhq.com>
- Made the emoji btn blue when composer is focused
- Moved everything chat-composer-button to its own file and BEM-ified it and making the choice to only work with our own is-disabled definition instead of with the attribute :disabled, for consistency
This should fix this failure:
```
Failures:
1) Thread list in side panel | full page when there are no threads that the user is participating in shows a message
Failure/Error: measurement = Benchmark.measure { example.run }
expected to find text "You are not participating in any threads in this channel." in "Community\nEverything\nMy Posts\nMore\nMessages\nInbox\nChannels\nRandom 25\nPersonal chat\nRandom 25\nShowing all messages\nOngoing discussions"
```
The screenshot failure was clearly showing the spinner still being present.
Rescuing them still makes timing-out tests fail but doesn't break `after` spec cleanup (which could trigger more errors) Using custom error class to avoid any other possible timeout-catching code.
Also:
* remove an unnecessary `.select { |x| x.size > 0 }`
* fix a typo in a test title
We were calling reset without the proper params which was causing errors in the console. This commit does the following changes:
- ensures `composer.cancel()` is the only way to cancel editing/reply
- adds a `draftSaved` property to chat message to allow for better tests
- writes a spec to ensure the flow is correct
- adds more page objects for better tests
- homogenize the default state of objects on chat message
Co-authored-by: Martin Brennan <martin@discourse.org>
Editing a message to an empty string and sending it, will delete it.
This commit also refactors a lot of channel/thread composer shortcuts specs.
---
This commit also includes various spec fixes which have been flakey while finishing this pull request.
These specs were disabled in 786f7503. While investigating this, I found out that at some point `:user_membership` got deleted. It's hard to tell why exactly without investing more time, but it seems using `let!` instead of `fab!` solves the issue.
If in the future we decide to investigate why these tests were flaky with `fab!` to reproduce the failure run:
LOAD_PLUGINS=1 rspec --seed 46586 plugins/chat/spec/mailers/user_notifications_spec.rb
This changes the thread header positioning of the
unread indicator to match the designs based on the route:
1. When the channel is open, show the indicator of # unread
threads with the icon
2. When the threads list is open, show no indicator since
you are on the list and can see which threads are unread
3. When a single thread is open, show the unread threads
indicator along with a left < back button, with a label
to show that this goes back to ongoing discussions
Drawer changes to come in another PR.
Why is this change required?
In the `PageObjects::Components::Chat::Messages#has_no_message?` method,
it ended up calling `has_selector` when trying to assert that the
selector is not present. This is an anti-pattern which results in us
waiting the full Capybara default wait time
What is this change required?
In the `chat/spec/system/transcript_spec.rb` test, there is a helper
method that uses `page.has_css?` in a conditional but it do not
specify a wait time and hence the default Capybara default max wait
time is used. However, there is no need for us to be waiting here so
we specify the `wait: 0` option.
Followup 55ef2d0698.
In the cases where the user has no last_read_message_id for
a channel, we want to make sure that a page_size is set for
the ChannelViewBuilder + MessagesQuery, otherwise we end up
loading way more messages than needed (the additional message
loading was fixed in the last commit).
This commit introduces a couple of changes:
1. When editing a chat channel's slug, we were using `this.model.set("title", title)` when the `set`
function does not exist. This was actually throwing the error in the
"can edit slug" system test where the modal was not closed after
saving and was flashing an error.
2. Introduce `PageObjects::Pages::ChatChannelAbout` and
`PageObjects::Modals::ChatChannelEdit` page object to encapsulate
logic better.
When a thread is created / a new message is created in the
thread, we want to make sure that the original message user
has a membership for that thread, otherwise they will not
receive unread indicators for messages in the thread.
This commit attempts to fix the case where the messages loaded initially don't fill the screen. It would prevent user to scroll and as a result to load more.
There are multiple fixes in this commit:
- the main fix is removing this code which was preventing the actual fill:
```javascript
// prevents an edge case where user clicks bottom arrow
// just after scrolling to top
if (loadingPast && this.#isAtBottom()) {
return;
}
```
- ensures we always give a page site to the `chatApi.channel(...)` call if we have one, in the current state when `fetchFromLastRead` was `true` we would not set `args.page_size`
- ensures the `query_paginated_messages` is having a valid page size, which is not nil and not > `MAX_PAGE_SIZE`
- write a spec for the autofill, it was a challenging spec to write but it should give us the confidence we need here
Since 5cce829 and the new
channel view builder, we have no need of these obsolete
routes which have way too much logic in the controller, which
has been superseded by the view builder anyway.
Remove the routes and update the channel message loading to use it.
* Moved the settings cog from thread list to thread and
put it in a new header component
* Remove thread original message component, no longer needed
and the list item and thread indicator styles/content
will be quite different
* Start adding content (unread indicator etc.) to the thread
list item and changing structure to be more like designs
* Serialize the last thread reply when opening the thread index,
show in list and update with message bus
The current behavior is to close drawer when pressing escape inside the input.
After this change, first escape will blur the input, and second escape will close the drawer.
This commit also refactors the whole shortcuts for drawer system spec.
Followup to d4a5b79592,
this introduced an N1 because every message in the list
we had to query users for the mentions and then the user's
status too. Instead we can just include both in Chat::MessagesQuery.
#### FIX: Do not use client lastReadMessageId when fetching channel messages
We had an issue where the following happened:
1. User opened channel and saw the last message, and we set the
lastReadMessageId on the server and the client
2. User navigated to another channel
3. Another user deleted the message in the original channel
4. The first user navigated back to the original channel before
the MessageBus event for the deleted message arrived, and got
a 404 error because we were sending the deleted lastReadMessageId as
target_message_id to the channel controller.
Instead of this which is a bit flaky and is hard to cover all
the issues for, instead we can pass a fetch_from_last_read boolean
param to the channels controller, and just get the user's
last_read_message_id straight from the database to use for the
target_message_id. This gets rid of any sources of race conditions
or lack of updates from MessageBus.
#### FIX: Include missing memberships for thread tracking publish
When we publish the channel/message tracking state for a
user and that message was a thread reply the publisher
was erroring because we were not telling Chat::TrackingStateReportQuery
to return missing memberships (which have zeroed out unread counts)
as well, which is what we do for the channel tracking state here.
Also just make sure that the TrackingStateReport does not error
when passed an ID it doesn't have data for.
This flakey has been very visible by the new headless chrome. The problem was that after moving a message we automatically redirect to the channel where the message has been moved to. However, we were not explicitly waiting for this transition and a result it could happen that we attempt to check the presence of the message on the channel page before the redirect actually happened.
The various naming changes are due to an early mistake we made in chat specs to use `chat` as the variable name for the page object which prevents to use the automatic path `chat.channel_path(...)`.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
This commit follows up b6c5a2da08
by serializing the user's thread memberships in these cases:
1. When we do the initial channel fetch with messages, we get
all threads and all the user's thread memberships for those
messages.
2. When the thread list is fetched, we get all the user's memberships
in that list.
3. When the single thread is fetched, either from opening it from
the list, an OM indicator, or just from doing .find() on the
manager when a new MessageBus message comes in
This will let us track the lastReadMessageId on the client, and
will also let us fix an issue where the unread indicator in the
channel header was incrementing for every thread that got a
new message, regardless of whether the user was a member.
This patch introduces policy objects to chat services. It allows putting
more complex logic in a dedicated class, which will make services
thinner. It also allows providing a reason why the policy failed.
Some change has been made to the service runner too to use more easily
these new policy objects: when matching a failing policy (or any failing
step actually), the result object is now provided to the block. This
way, instead of having to access the reason why the policy failed by
doing `result["result.policy.policy_name"].reason` inside the block,
this one can be simply written like this:
```ruby
on_failed_policy(:policy_name) { |policy| policy.reason }
```
This commit adds the thread index and individual thread
in the index list unread indicators, and wires up the message
bus events to mark the threads as read/unread when:
1. People send a new message in the thread
2. The user marks a thread as read
There are several hacky parts and TODOs to cover before
this is more functional:
1. We need to flesh out the thread scrolling and message
visibility behaviour. Currently if you scroll to the end
of the thread it will just mark the whole thread read
unconditionally.
2. We need to send down the thread current user membership
along with the last read message ID to the client and
update that with read state.
3. We need to handle the sidebar unread dot for when threads
are unread in the channel and clear it based on when the
channel was last viewed.
4. We need to show some indicator of thread unreads on the
thread indicators on original messages.
5. UI improvements to make the experience nicer and more
like the actual design rather than just placeholders.
But, the basic premise around incrementing/decrementing the
thread overview count and showing which thread is unread
in the list is working as intended.
This should also make `message_notifications_with_sidebar_spec.rb` more resilient as we are now checking for `is-persisted` class instead of checking for the absence of `is-staged`.
This commit attempts to correctly change draft when the channel changes. It moves responsibility to the composer instead of the channel.
A new service `chatDraftsManager` is being introduced here to allow finer control and pave the way for future thread draft support.
These changes also now allow an editing message to be stored as a draft.
This PR adds status to mentions in chat and makes those mentions receive live updates.
There are known unfinished part in this implementation: when posting a message, status on mentions on that message appears immediately, but only if a user used autocomplete when typing the message. If user copy and paste a message with mentions into chat composer, those mentions won't have user status on them.
PRs with fixes for both problems are following soon.
Preparations for this PR that were made previously include:
- DEV: correct a relationship – a chat message may have several mentions 0dcfd7ddec
- DEV: extract the logic for extracting and expanding mentions from ChatNotifier 75b81b6854
- DEV: Always create chat mention records fa543cda06
- DEV: better split create_notification! and send_notifications logic e292c45924
- DEV: more tests for mentions when updating chat messages e7292e1682
- DEV: extract updating status on mentions into a lib function e49d338c21
- DEV: Create and update chat message mentions earlier 35a414bb38
- DEV: Create a chat_mention record when self mentioning 2703f2311a
- DEV: When deleting a chat message, do not delete mention records f4fde4e49b
In the ChannelViewBuilder, we introduced a check to see if
the target message exists, which errors if the message has
been trashed. However if the user is the creator of the message
or admin then they are able to see trashed messages, so
we need to take this into account.
Followup to c908eeacc9
Instead of using the latest message ID in the channel, which
could cause issues if you have an earlier last read message ID
that matches the deleted one, instead we use the first non-deleted
message that comes before the deleted message by ID.
Followup ae3231e140, when a
message is trashed we already update the lastReadMessageId of
all users in the channel to the latest non-deleted message on
the server side. However we didn't propagate this to the client,
so in some cases when we did the following:
1. Delete the last message in the channel
2. Switch to another channel
3. Switch back to the original
We would get a 404 error from the target message ID being looked
up still being the old lastReadMessageId (now deleted) for the
user's channel membership.
All we need to do is send the last not-deleted message ID for
the channel (or thread) to all the member users.
It easier to check for presence in this case that to check for something not present, as depending on performance of the machine running the test this could take sometime to be changed and the test would fail.
This issue was especially visible in tests. the `@debounce(100)` was not cancelled when changing channel which was causing 404s as we were trying to load messages on a channel which was deleted as the channel has been destroyed at the end of the test.
This is still not a perfect solution, as we can only cancel the start of `fetchMessages`, but we can't cancel the actual `chatApi.channel` request which result can potentially happens after channel changed, which we try to mitigate with various checks on to ensure visible channel == loaded messages channel.
This commit also tries to make handler naming and cancelling more consistent.
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
This commit makes some fundamental changes to how hashtag cooking and
icon generation works in the new experimental hashtag autocomplete mode.
Previously we cooked the appropriate SVG icon with the cooked hashtag,
though this has proved inflexible especially for theming purposes.
Instead, we now cook a data-ID attribute with the hashtag and add a new
span as an icon placeholder. This is replaced on the client side with an
icon (or a square span in the case of categories) on the client side via
the decorateCooked API for posts and chat messages.
This client side logic uses the generated hashtag, category, and channel
CSS classes added in a previous commit.
This is missing changes to the sidebar to use the new generated CSS
classes and also colors and the split square for categories in the
hashtag autocomplete menu -- I will tackle this in a separate PR so it
is clearer.
