Previously, it will add a "Re:" prefix to all the emails passing through the group SMTP mailer. It's creating confusion while receiving the mail for the first time on a PM.
1. `everything` was changed to `topics`
2. Path for my posts translation is `sidebar.sections.community.links.my_posts.content` not `sidebar.sections.community.links.my/posts.content`
- 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. -->
Different environments run on different hardware so response times vary
based on hardware. Instead of hardcoding the timeout for
`SystemHelpers#try_until_success` to 2 seconds, we change it such that
it follows `Capybara.default_wait_timeout` which we have configured to
be higher in environments which runs on lousier hardware.
This change should reduce the amount of flakiness we're seeing on CI
with tests that rely on `SystemHlpers#try_until_success`.
The work in fa509224f0 updated our initializer patterns to match modern Ember. This caused the initializer from the (deprecated) ember-export-application-global addon to change its behavior from exporting the ApplicationInstance to exporting the Application. This affects customizations which were using some long-deprecated APIs we had attached to the ApplicationInstance.
This commit removes the deprecated addon, restores the previous ApplicationInstance behavior which we've come to depend on, and adds a test for the expected behavior. It also bumps the `dropFrom` version to make it clear that we do not intend to remove these APIs during this release cycle.
Upstream added a capital 'T' to the 'Translation missing' message in https://github.com/ruby-i18n/i18n/commit/c5c6e753f3. This caused our translate accelerator patch to diverge, and the change in case affected a number of our specs. This commit updates the translate accelerator to match the upstream casing, and introduces a spec to detect future divergence.
# Top level view
This PR is the first version of converting the search menu and its logic from (deprecated) widgets to glimmer components. The changes are hidden behind a group based feature flag. This will give us the ability to test the new implementation in a production setting before fully committing to the new search menu.
# What has changed
The majority of the logic from the widget implementation has been updated to fit within the context of a glimmer component, but it has not fundamentally changed. Instead of having a single widget - [search-menu.js](https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse/app/widgets/search-menu.js) - that built the bulk of the search menu logic, we split the logic into (20+) bite size components. This greatly increases the readability and makes extending a component in the search menu much more straightforward.
That being said, certain pieces needed to be rewritten from scratch as they did not translate from widget -> glimmer, or there was a general code upgraded needed. There are a few of these changes worth noting:
### Search Service
**Search Term** -> In the widget implementation we had a overly complex way of managing the current search term. We tracked the search term across multiple different states (`term`, `opts.term`, `searchData.term`) causing headaches. This PR introduces a single source of truth:
```js
this.search.activeGlobalSearchTerm
```
This tracked value is available anywhere the `search` service is injected. In the case the search term should be needs to be updated you can call
```js
this.search.activeGlobalSearchTerm = "foo"
```
**event listeners** -> In the widget implementation we defined event listeners **only** on the search input to handle things such as
- keyboard navigation / shortcuts
- closing the search menu
- performing a search with "enter"
Having this in one place caused a lot of bloat in our logic as we had to handle multiple different cases in one location. Do _x_ if it is this element, but do _y_ if it is another. This PR updates the event listeners to be attached to individual components, allowing for a more fine tuned set of actions per element. To not duplicate logic across multiple components, we have condensed shared logic to actions on the search service to be reused. For example - `this.search.handleArrowUpOrDown` - to handle keyboard navigation.
### Search Context
We have unique logic based on the current search context (topic / tag / category / user / etc). This context is set within a models route file. We have updated the search service with a tracked value `searchContext` that can be utilized and updated from any component where the search service is injected.
```js
# before
this.searchService.set("searchContext", user.searchContext);
# after
this.searchService.searchContext = user.searchContext;
```
# Views
<img width="434" alt="Screenshot 2023-06-15 at 11 01 01 AM" src="https://github.com/discourse/discourse/assets/50783505/ef57e8e6-4e7b-4ba0-a770-8f2ed6310569">
<img width="418" alt="Screenshot 2023-06-15 at 11 04 11 AM" src="https://github.com/discourse/discourse/assets/50783505/2c1e0b38-d12c-4339-a1d5-04f0c1932b08">
<img width="413" alt="Screenshot 2023-06-15 at 11 04 34 AM" src="https://github.com/discourse/discourse/assets/50783505/b871d164-88cb-405e-9b78-d326a6f63686">
<img width="419" alt="Screenshot 2023-06-15 at 11 07 51 AM" src="https://github.com/discourse/discourse/assets/50783505/c7309a19-f541-47f4-94ef-10fa65658d8c">
<img width="424" alt="Screenshot 2023-06-15 at 11 04 48 AM" src="https://github.com/discourse/discourse/assets/50783505/f3dba06e-b029-431c-b3d0-36727b9e6dce">
<img width="415" alt="Screenshot 2023-06-15 at 11 08 57 AM" src="https://github.com/discourse/discourse/assets/50783505/ad4e7250-040c-4d06-bf06-99652f4c7b7c">
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
Today I learnt that `has_link?("text of link")` by default does an
includes instead of looking for a link with the exact text. This is not
the behaviour I want so I'm changing
`PageObjects::Components::Sidebar.has_section_link?` to use the
`exact_text` option instead.
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.
What this change?
Previous solution relied on CSS to hide the header which is first
wasteful since we're still rendering the header and second makes it
untestable. If we don't want the header to show, we should avoid
rendering it in the first place.
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.
Added a new modifier hook to allow plugins to modify the @mentions
extracted from a cooked text.
Use case: Some plugins may change how the mentions are cooked to prevent
them from being confused with user or group mentions and display the user
card.
This modifier hook allows the plugin to filter the mentions detected or add new ways
to add mentions into cooked text.
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
