* 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.
Cater for polls that can have multiple votes per user.
This fixes an older UserMerge and migration which was intended to
de-duplicate poll votes but did not account for "multiple" type polls.
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
```
- gridified the thread message indicator, alleviating some problems with positioning and overflow
participant avatars will overlap/smush on smaller size and mobile
- the excerpt went from 3 > 2 lines of wrapping on smaller size, still 1 line on large size
- dropped the copy of "last reply"
- fixed wrong line height
- moved the "x replies" over to the right near the participants, as that makes more sense
- using a bubble to indicate other participants, instead of copy
This PR introduces the @container query, which is experimental. Nothing will break when it's being viewed in a not-supported browser, but it will be less elegant.
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 should prevent the message to show as active on mobile when making a touch to start scrolling.
This commit also makes naming of touch lifecycle functions coherent.
We had a bug in this code recently, sometimes users saw weird notifications
like:
User mentioned all_mentioned_user_ids in the help chat channel
We fixed that bug in b85d057.
This refactoring is a follow-up to that fix. As that bug showed, it’s quite easy
to introduce a key that may end up being sent to the `NotifyMentioned` job,
which can lead to such weird notifications. This refactoring makes sure that
the `to_notify` hash contains only IDs of users that should be notified about
mentions.
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. -->
Previously this was defining methods like `UserOption#never?`, `UserOption#all_new?`, `UserOption#dm_and_mentions?`. Now they will be prefixed like `UserOption#chat_header_indicator_never?`
The layout was broken for messages replying to another message in non threaded channels.
This commit also refactors the chat-message-test to use fabricators.
Unfortunately, Discourse's `UserOption` model is not currently autoloaded. That means that modifying it via a `reloadable_patch` will try to apply the changes repeatedly. Normally this doesn't matter since the changes are idempotent. However, introducing ActiveRecord enums is not idempotent - they raise an error if the same enum already exists on the model. This commit adds a check to avoid hitting this 'duplicate definition' error.
Reproduced
```
rails runner 'Rails.application.reloader.reload!'
```
- 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.
Why is this change required?
When a site is newly setup and a user has just been created, the
categories and tags sections are hidden from the user. This happens
because the admin has not configured the `default_navigation_menu_categories` or
`default_navigation_menu_tags` site settings. When the categories and tags
sections are hidden from the user, the sidebar looks extremely bare and
does not create a good experience.
What is being change?
In this commit, we're changing the logic such that the site's top
categories and tags are displayed if the user does not have any
categories/tags configured in each respective section. The only
regression introduced in this change is that the categories and tags
section can no longer be hidden as a result. However, we have plans to
address this in the future by allowing sidebar sections to be configured
to be hidden by each individual user.
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.
https://meta.discourse.org/t/updating-our-initializer-naming-patterns/241919
For historical reasons, Discourse has different initializers conventions than standard Ember:
```
| Ember | Discourse | |
| initializers | pre-initializers | runs once per app load |
| instance-initializers | (api-)initializers | runs once per app boot |
```
In addition, the arguments to the initialize function is different – Ember initializers get either the `Application` or `ApplicationInstance` as the only argument, but the "Discourse style" gets an extra container argument preceding that.
This is confusing, but it also causes problems with Ember addons, which expects the standard naming and argument conventions:
1. Typically, V1 addons will define their (app, instance) initializers in the `addon/(instance-)initializers/*`, which appears as `ember-some-addon-package-name/(instance-)initializers/*` in the require registry.
2. Just having those modules defined isn't supposed to do anything, so typically they also re-export them in `app/(instance-)initializers/*`, which gets merged into `discourse/(instance-)initializers/*` in the require registry.
3. The `ember-cli-load-initializers` package supplies a function called `loadInitializers`, which typically gets called in `app.js` to load the initializers according to the conventions above. Since we don't follow the same conventions, we can't use this function and instead have custom code in `app.js`, loosely based on official version but attempts to account for the different conventions.
The custom code that loads initializers is written with Discourse core and plug-ins/themes in mind, but does not take into account the fact that addons can also bring initializers, which causes the following problems:
* It does not check for the `discourse/` module prefix, so initializers in the `addon/` folders (point 1 above) get picked up as well. This means the initializer code is probably registered twice (once from the `addon/` folder, once from the `app/` re-export). This either causes a dev mode assertion (if they have the same name) or causes the code to run twice (if they have different names somehow).
* In modern Ember blueprints, it is customary to omit the `"name"` of the initializer since `ember-cli-load-initializers` can infer it from the module name. Our custom code does not do this and causes a dev mode assertion instead.
* It runs what then addon intends to be application initializers as instance initializers due to the naming difference. There is at least one known case of this where the `ember-export-application-global` application initialize is currently incorrectly registered as an instance initializer. (It happens to not use the `/addon` folder convention and explicitly names the initializer, so it does not trigger the previous error scenarios.)
* It runs the initializers with the wrong arguments. If all the addon initializer does is lookup stuff from the container, it happens to work, otherwise... ???
* It does not check for the `/instance-initializers/` module path so any instance initializers introduced by addons are silently ignored.
These issues were discovered when trying to install an addon that brings an application initializer in #22023.
To resolve these issues, this commit:
* Migrates Discourse core to use the standard Ember conventions – both in the naming and the arguments of the initialize function
* Updates the custom code for loading initializers:
* For Discourse core, it essentially does the same thing as `ember-cli-load-initializers`
* For plugins and themes, it preserves the existing Discourse conventions and semantics (to be revisited at a later time)
This ensures that going forward, Ember addons will function correctly.
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
When merging users, polls may error out if the source and target users have both voted on the same poll before. 😢
There is no constraint on the `poll_votes` table either to support this. Ideally a composite primary key can be used `(poll_id, user_id)`, but alas there is no support yet, which is probably why it wasn't created in the first place.
This fix ensures that merging is successful by only keeping the target poll votes if duplicates exist.
This fix also runs a migration on older poll votes where failed merges would have caused a single user to have voted twice on a single poll. e.g. this weird edge case
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>
Since we created user_chat_thread_memberships in
cc2570f we haven't
yet backfilled it for users who previously sent a message in
in threads -- this migration creates the UserChatThreadMemberships
needed for those threads, making sure the last read message id
is accurate for those participants.
* 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'
In early 2015, the poll plugin was writing its data to custom fields on
the post containing the poll. It was later changed to have dedicated SQL
tables and the polls were migrated but we forgot to clean the existing
data.
* 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>
This is actually making things more sluggish than necessary. If any perf issue happen out of this they should be handled in the consequences of the resizing, not the resizing itself.
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
We have been struggling a lot on this lately as it's almost impossible to write a decent test for this.
The important things which need to happen:
- fetch the unread/mention state and last message bus channel ids of each chat channels
- stop all subscriptions
- restart global chat subscriptions
- update channels with new state and ensure the message bus ids are updated
- restart subscriptions of each chat channel
As a followup we need to start implementing a standard way to query for a resource state. Something similar to: `/channels/tracking` and `/channels/:id/tracking`
Each of these endpoints would return a state similar to:
```json
{
tracking: { ... },
message_bus_ids: { ... }
}
Removing a reaction could start a long press at the same time and put the screen in a stuck state.
This commit ensures we give an opportunity to the reaction to capture the event first and not propagate further.
These spec are flaky only in CI, not locally and not in GitHub actions.
The previous attempt was in 44eabde, but actually the failure happens
a bit earlier. This is another attempt to fix these specs. Quite a lot of
async logic is happening in emulateAutocomplete(), a call to settled()
in the end should help make it more reliable.
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.
In some cases, plugins may want to hide some of these actions
at all times, overriding the rules for canX with hiding these
buttons. To achieve this, a plugin can call the API
`removeChatComposerSecondaryButtons` and pass the list of button
IDs that should be removed as argument, like the example below:
```
withPluginApi("1.2.0", (api) => {
api.removeChatComposerSecondaryActions("copyLink", "select");
});
```
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
These specs were skipped in d6d5eae1. They sometimes failed, and only on CI,
not in GitHub Actions.
I wasn't able to reproduce failures locally, but I expect clicking the send button
in chat composer should be more reliable than emulating pressing <kbd>Enter</kbd>.
When editing a message, we call `message.cook()` in the beginning of
`#sendEditMessage` methods, but when sending a new message,
the call to `message.cook()` is hidden in the `stageMessage` method.
We can just call `message.cook()` before sending the message, no matter
whether this is a new message or an edited message.
No test as this is very much a hack while lightbox is being revamped. We currently have no good/easy way AFAIK to stop event propagation on escape in magnificpopup.
This behavior has been possible for a long time and has been made more in recent commits. On PWA iOS when release the touch after the mobile actions menu has been shown, if the finger was over one of the buttons of the menu, it would trigger a click.
This commit should now correctly trap and cancel events.
The following case would create the perception of a broken back button on desktop:
- open discourse on home page
- click chat button in header
- hit back button
- observes that we are still on the channel didn't navigate to homepage as we would have expected
The back button is actually working but it's in a loop. We were doing a `transitionTo` after finding the ideal channel to show, so the browser history would look something like this:
- home
- chat index
- channel page
When hitting back, we would go to chat index which would run the same logic and transition us to channel page.
This change will use `replaceWith` to replace the chat index step by the channel step, this way our history will now look like this:
- home
- channel page
Hitting back will now correctly bring us to home.
This commit attempts to refactor our long press logic to make it more resilient and precise.
With this improvement two very UX/UI changes have been made:
- scale animation on long press
- prevents click on reaction to propagate to the message which would cause the active state of the message to trigger
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.
Followup to e6c6c342d9,
we missed one part of this refactor which was to give
the correct composer element reference to ChatComposerUploads.
Without this the pasteEventListener for uploads was not
bound so uploading via paste did not work.
I tried to test this, and though I can write binary/text to
the clipboard and paste it into the composer, it does not
seem to be possible to end up with a paste event that
has clipboardData.files filled in, which is what is used
for the uploads. I think this is a restriction of JS
generally, and there doesn't seem to be a way to work around
it, so unfortunately we have to have no test for this still.
Usually, when a user is promoted to TL2 two messages are sent. The
first one is a system message 'tl2_promotion_message' which triggers a
'system_message_sent' Discourse event.
When the event is fired and if Discourse Narrative Bot is enabled, then
a second message is sent to the recipient of the first message. The
recipients was determined by looking at the list of users that can
access that topic and pick the last one. This method does not work if
'site_contact_group_name' site setting is set because it adds the group
in the list of recipients.
A solution to this problem would have been to select the last user in
the list of 'topic_allowed_users', but an even better solution is to
pass the name of the recipients when the 'system_message_sent'
Discourse event is fired.
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
Previously, there was an issue where closing the message actions menu on mobile would unintentionally trigger a click event on an element below it, such as a thread indicator or a reaction. With the recent fix, this problem has been resolved. Now, when you close the menu, it will no longer interfere with or activate any elements positioned underneath it.
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.
Few weeks ago we implemented `onPresenceChangeCallback` to re-sync chat channels state when going back to a long time inactive tab. This codepath however contained a bug as we were reseting all subscriptions but only restarting global subscriptions and not per channel subscriptions.
This commit should correctly ensure we correctly do so. It's sadly very hard to test time related changes in system specs.
Co-authored-by: Martin Brennan <mjrbrennan@gmail.com>
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.
When a user type a message with mentions, the autocomplete popup
may suggest users or groups. We were adding all these object to
the `currentMessage.mentionedUsers` collection, while we should
have been adding only users. A group added to that collection led to
the error later when trying to update user status on mentions.
This will make it simpler to work with this code. This also can make this code more stable and increase stability of our test suite.
Cooked message now will be available immediately after cooking, it wasn't the case before:
await message.cook();
const cooked = message.cooked;
This also removes a call to `message.cook()` from message fabricator. Alternatively we may leave the call there and make the fabricator function async, but I fill it's better this way. If someone needs to test something related to cooked message, they can either pass cooked text to fabricator:
message = fabricators.message({ cooked: "<p>cooked</p>" });
or call `message.cook()` after fabrication:
message = fabricators.message({ message: "raw message" });
await message.cook()
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>
- ensures buttons are aligned to the bottom
- makes the emoji icon tertiary as initially intended
- correctly sets the icon scale of the sending button
- 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.
If the drawer receives an unexpected route, attempt to show the index. This is probably a more serious issue with subfolder but should limit the effects.
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
In some cases activeChannel can be null so this will error,
also it is limiting to have this code in chatApi. Instead
move to the threads manager, and also lean on channelsManager.find
to get the channel from the cache instead, which will not error.
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 commit regroups 3 changes
- serializes channel ID and json draft when calling the debouncer instead of inside the debounced function, it seems very unlikely to happen, but in a case where the debouncing wouldn't be canceled and the new message not set yet, we could save the draft on an invalid channel
- cancel persist draft handler when changing channel
- ensures we exit early when channel is not set
Very fast or specific mouse moves could allow to leave a message actions menu without reseting the active message. This commit should ensure we correctly catch this event.
No test as it's hard and not reliable to reproduce these in a test.
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.
