`#main` in the test environment is replaced with `#ember-testing`, so this code would break. It never did only because we don't test these code paths 👀
The logic was added in commit ec8306835d,
to show the like action even if the user could not like the post. It is
not necessary for this logic to be implemented on the server side.
* FIX: Do not allow to remove like if topic is archived
* FIX: Always show like button
The like button used to be hidden if the topic was archived and it had
no likes. This commit changes that to always show the like button, but
with a not-allowed cursor if the topic is archived.
When `EMBER_CLI_PLUGIN_ASSETS=1`, plugin application JS will be compiled via Ember CLI. In this mode, the existing `register_asset` API will cause any registered JS files to be made available in `/plugins/{plugin-name}_extra.js`. These 'extra' files will be loaded immediately after the plugin app JS file, so this should not affect functionality.
Plugin compilation in Ember CLI is implemented as an addon, similar to the existing 'admin' addon. We bypass the normal Ember CLI compilation process (which would add the JS to the main app bundle), and reroute the addon Broccoli tree into a separate JS file per-plugin. Previously, Sprockets would add compiled templates directly to `Ember.TEMPLATES`. Under Ember CLI, they are compiled into es6 modules. Some new logic in `discourse-boot.js` takes care of remapping the new module names into the old-style `Ember.TEMPLATES`.
This change has been designed to be a like-for-like replacement of the old plugin compilation system, so we do not expect any breakage. Even so, the environment variable flag will allow us to test this in a range of environments before enabling it by default.
A manual silence implementation is added for the build-time `ember-glimmer.link-to.positional-arguments` deprecation while we work on a better story for plugins.
When there is not enough window width to display the admin menu on the
right, we display it on the left instead. Behavior is reversed on RTL
layout.
This commit also removes jQUery usage.
`TopicQueryParams` allows for `match_all_tags` to be passed as a query parameter. `TagsController` forces the value to be true.
This change allows a value to be passed, and only sets it to true if no value has been set. It then uses `ActiveModel::Type::Boolean.new.cast` to compare the value.
This commit adds the profile tab to the experimental user menu. We're adding it to the user menu because it contains links/buttons that are not available anywhere else. We may remove the tab again if we find better places for those links/buttons, but for now it'll stay.
For more context on the experimental user menu, see https://github.com/discourse/discourse/pull/17379.
This regressed when we switched these bundles to be compiled by ember-cli. Before/after sizes:
```
before after
admin.js: 1370 KB (190 KB gz) --> 782 KB (125 KB gzipped)
wizard.js: 127 KB ( 22 KB gz) --> 68 KB ( 18 KB gzipped)
```
The logic to determine what post excerpt to show for
a topic-level bookmark based on the last unread post
was complex and slow, so we decided to remove it and
always just use the first post excerpt.
This commit also fixes an issue where a couple of
instances of for_topic were missed when doing the
Bookmarkable refactors, so:
1. Clicking the topic bookmark link was not taking
the user to the last unread post
2. When replying to a topic where there was a topic
level bookmark with the auto delete preference
of "on owner reply", we were not removing the
bookmark from the UI correctly.
A test has been added for the former, the latter would
be quite time-consuming to test and not really worth
it considering it's quite an edge case UI bug.
Ever opened `/tests`, immediately tried to change the config, and got frustrated that focus keeps getting stolen by the running tests? Worry no more - this commit will make the tests auto-abort when you click any of the input/dropdowns in the QUnit header. It's not perfect - abort will wait until the end of the currently running test, so sometimes focus will be stolen one more time. But it's still a lot better than having to manually find and click the abort button.
The maximum_staged_users_per_email site setting controls how many
staged users will be invited to the topic created from an incoming
email. Previously, it counted only the new staged users.