The old logic did not make sense and hid the selector from regular users
even if they could tag PMs or showed selector for admins even if they
could not tag PMs.
The preload key was changed in e7a84948b9 but this location was missed. This caused an extra AJAX request and left the cached topic list in the PreloadStore, which would then be accidentally used when navigating to the next topic-list route.
This commit extends the plugin API introduced in 40fd82e2d1 to the `Bookmark` and `Notification` models. It also refactors the code that's responsible for loading items in the experimental menu to use `async`...`await` instead of `Promise`s.
This API allows plugins to transform a list of model objects before they're rendered in the UI. At the moment, this API is limited to items/lists of the experimental user menu, but it may be extended in the future to other parts of the app.
Additional context can be found in https://github.com/discourse/discourse/pull/18046.
The previous sprockets implementation was including admin-specific JS in the plugin's main JS file, which would be served to all users regardless of admin status. This commit achieves the same result under the ember-cli plugin asset compiler with one difference: the admin js is compiled into a separate file. That means that in future, we'll be able to make it loaded only for admins. For now though, it's loaded for everyone, just like before.
When preloading topic_list data we were giving it a 'preload key' which was loosely based on the parameters of the list. However, it did not include all parameters, and mismatches between client/server-side logic would cause the preloaded data to be ignored.
This commit simplifies things by using a single key for all topic_list preloading. This works on the assumption that "The first topic_list the JS app will load is the one which was preloaded". That assumption also existed to some extent in the old design, so we don't expect any regressions here.
Omitting the flag from optional-features enables the runtime deprecation notice.
Also introduces `ember-jquery-legacy` which can be used to migrate to the new behaviour early. Details at https://deprecations.emberjs.com/v3.x/#toc_jquery-event
Core does not appear to make use of `originalEvent` in Ember event handlers. When searching for `originalEvent` there are some matches which relate to our pan-events mixin, but this is our own implementation and not affected by this deprecation.
Plugins often change core behavior, and thereby cause core's tests to fail. In CI, we work around this problem by running core CI without any plugins loaded.
In development, the only option to safely run the core tests is to uninstall all plugins, which is clearly a bad developer experience. This commit aims to improve that experience.
The `qunit_skip_plugins=1` flag would previously prevent the plugin **tests** from running. This commit extends that flag to also affect the plugin's application JS.
Default sidebar tags for not authenticated users can be defined in admin panel. Otherwise, top 5 categories and tags are taken.
Optionally, if categories are set up in permanent order, then the first 5 categories are taken.
`#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.
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 following changes are made in this commit:
1. Move caret icon in sidebar section header to the right.
1. Each row in sidebar takes the full width which enables us to do a
full width highlight on hover and when sidebar link is active.
1. Ensure each row in Sidebar is of the same height.
Internal refs: /t/70546, /t/72196, /t/71820
These packages are not published anywhere - they only exist for organizational purposes within this repository. Even so, it makes sense for their metadata to match that of the top-level discourse/discourse repository.
By default, in CI environments, Ember CLI does not output anything between "building..." and "cleaning up". Depending on configuration and hardware, Discourse asset builds can take upwards of 60s, and so this lack of output can make the build feel 'stuck'.
This commit introduces an addon which checks for CI mode, and then outputs status information periodically. The logic is very similar to Ember CLI's non-CI progress output implementation (https://github.com/ember-cli/ember-cli/blob/04a38fda2c/lib/models/builder.js#L183-L185).
Without this filter, a binary file (e.g. `.DS_Store`) in one of these addon directories will be concatenated into the output JS. Note that this filter is applied at the end of the build pipeline, so any hbs files have already been transpiled into `.js`.
This mirrors the filtering performed on the main application bundle by Ember CLI: https://github.com/ember-cli/ember-cli/blob/04a38fda2c/lib/broccoli/default-packager.js#L1255
We can finally rely on template colocation in our app and we'll be
standarizing on that in the near future. However, I want to have sidebar
adopt this convention earlier.
Instead of relying on another help to generate the icons, we want to
rely on the interface for adding prefix icons. This ensures that prefix
icons are consistent across the section links in Sidebar
If a widget toggles between displaying two different RenderGlimmer instances, the Widget framework treats them as the same, and so `update()` is called rather than destroy/init. This commit detects this scenario and manually destroys/inits to ensure the correct component is being rendered.
Before this commit, we carried custom code and styles for the sidebar on
mobile. This meant the look and feel of bringing up the sidebar on
mobile was very different from the user menu resulting in a very
inconsistent experience on mobile. Also, we could not leverage on the
existing swipe to close support on mobile.
In this commit, we made it such that the sidebar dropdown is always
rendered on mobile and made the interaction with the dropdown more
consistent with the user menu. There is also more parity with the old
hamburger dropdown when the experimental sidebar is disabled.
This commit introduces a new `{{on-resize}}` modifier along with its companion `resize-observer` Service. These automatically take care of setting up the observer and handling cleanup.
This commit includes the changes proposed in #17823. I've made these changes so that plugins that need to add tabs/lists with mixed item types - like the bookmarks tab that displays notifications and bookmarks - to the menu, don't have to write 2 templates like we currently do for the bookmarks/messages tabs (see user-menu/bookmark-notification-item.js that has been deleted in this commit).
These are in widespread use, and upgrading themes/plugins right now would break their compatibility with the stable branch. These should be unsilenced for the release of 2.9.0 stable.
Previously, this would require manually adding `?safe_mode=...` multiple times during the email-based login flow. `/u/admin-login` is often used when debugging a site, so it makes sense for this to be easier.
This commit introduces a new checkbox on the `/u/admin-login` screen. When checked, it'll set the safe_mode parameter on the `/email-login` link, and then pass it all the way through to the homepage redirect.
- `no_custom` -> `no_themes` (history: before themes existed, we had a similar tool called 'customizations')
- `only_official` -> `no_unofficial_plugins` (matches format of `no_themes` and `no_plugins`, and makes it clear that this doesn't affect themes)
- `?safe_mode=no_themes%2C%no_plugins` -> `?safe_mode=no_themes,no_plugins` (the query portion of a URL does not require commas to be encoded. This is much nicer to read)
- If `no_plugins` is chosen from `/safe-mode` the URL generated will omit the superfluous `no_unofficial_plugins` flag
- Some tweaks to copy on `/safe-mode`
There was existing logic for this, but it was broken because the values were being run through `encodeURI` before checking its type. This commit takes the opportunity to modernise the function to use `URLSearchParams`, which means we no longer need to handle encoding/joining strings manually.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
This was a temporary solution while we updated the resolver and migrated all our singletons to true ember services. Now that's done, we can switch to use `@glimmer/component` directly, and explicitly inject services as required.
This fix is for the experimental user menu. Some `bookmark_reminder` notifications may not be associated with a topic/post (e.g. bookmark reminder for a chat message) in which case the default notification renderer cannot figure out the `href` for those `bookmark_reminder` notifications. This commit teaches the `bookmark_reminder` notification type renderer to fallback to `bookmarkable_url` that's present in the notification data if the default notification renderer doesn't return a `href` for the notification.
At a certain point, the cost of debugging a flaky acceptance test is
just too high for what we're testing for here. I've decided to just
accept the risk of a minor UX feature.
Follow-up to 55fa94f759
Previously, PM only tags were being routed to the public topic list with
the tag added as a filter. However, the public topic list does not fetch
PMs and hence PM only tags did not provide any value when added to the
Sidebar. This commit changes that by allowing the client to
differentiate PM only tag and thus routes the link to the PM tags show
route.
Counts for PM only tags section links are not supported as of this
commit and will be added in a follow up commit.
1. Replace `{{did-insert` with the builtin `{{on` modifier
2. Move the i18n call into the template
With both of those changes, there is no logic left in the backing class, so we can switch to `templateOnly()` which is significantly faster. (granted, not a big deal for a component like this, but it makes for a good demonstration)
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
This also updates `section-message` to be a templateOnly glimmer component rather than a classic component.
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
Makes displaying and hiding the list more deterministic.
```
Error: QUnit Test Failure: Exam Partition 1 - Acceptance: Sidebar - Community Section: clicking on more... link
not ok 491 Firefox 91.0 - [722 ms] - Exam Partition 1 - Acceptance: Sidebar - Community Section: clicking on more... link
---
actual: >
true
expected: >
false
stack: >
@http://localhost:7357/assets/core-tests.js:9826:14
message: >
additional section links are hidden
negative: >
false
browser log: |
```
A public key must be added to GitHub when installing private themes.
When the process happens asynchronously (for example if the admin does
not have admin permissions to the GitHub repository), installing
private themes becomes very difficult.
In this case, the Discourse admin can partially install the theme by
letting Discourse save the private key, create a placeholder theme and
give the admin a public key to be used as a deploy key. After the key
is installed, the admin can finish theme installation by pressing a
button on the theme page.
Some of the changes in this PR are extracted from https://github.com/discourse/discourse/pull/17379.
Similar to the bookmarks tab in the new user menu, the messages tab also displays a mix of notifications and messages. When there are unread message notifications, the tab displays all of these notifications at the top and fills the remaining space in the menu with a list of the user's messages. The bubble/badge count on the messages tab indicates how many unread message notifications there are.
* FEATURE: update bootstrap mode notice to add invite and wizard links
* Updates per feedback on PR
* Fix the wizard link not showing
* Remove unneeded function
* Remove router service injection
The new plugin list is based on the ones currently used in our ember-cli pipeline, and are based on our official browser support policy.
This commit includes an update to the raw-handlebars compiler to remove the 'very hacky but lets us use ES6' code. It's served us well for the last 6 years, but the babel config changes broke it (`const` -> `let`). This commit takes the opportunity to refactor it to take a similar approach to PrettyText, by leaning on `mini-loader.js`.
Some of the changes in this commit are extracted from https://github.com/discourse/discourse/pull/17379.
The bookmarks tab in the new user menu is different from the other tabs in that it can display a mixture of notifications and bookmarks. When there are unread bookmark reminder notifications, the tab displays all of these notifications at the top and fills the remaining space in the menu with the rest of the bookmarks. The bubble/badge count on the bookmarks tab indicates how many unread bookmark reminder notifications there are.
On the technical aspect, since this commit introduces a new `bookmark-item` component, we've done some refactoring so that all 3 "item" components (`notification-item`, `reviewable-item` and the new `bookmark-item`) inherit from a base component and get identical HTML structure so they all look consistent.
Internal tickets: t70584 and t65045.
We use the user-info component in several places, and we want to show status on some of them. If you want status to appear, do this:
{{user-info showStatus=true}}
Currently we can’t add a case-sensitive watched word if another one
exists with a different case. For example, the existing watched word
`Meta` has been created and is case-sensitive. Now an admin tries to add
`metA` while marking it as case-sensitive too, this won’t work and the
word won’t be added.
This patch changes this behavior by allowing to add same words that have
different cases, so the example above will now work as expected.
We still check for uniqueness but case-sensitivy is now taken
into account. It means that if the watched word `meta` already exists
and is not case-sensitive then it will not be possible to add `Meta`
(case-sensitive or not) as `meta` already matches every possible
variations of this word.
Prior to this commit, we had a default Glimmer component that was responsible for handling generic rendering of notifications in the user menu, and many notification types had a custom Glimmer component that inherited from the default component to customize how they were rendered. That implementation was less than ideal because it meant plugins would have to create Glimmer components to customize notification types added by them and that would make the surface area of the API too big.
This commit changes the implementation so there's only one Glimmer component for rendering notifications, and then notification types that need to be customized can create a regular JavaScript class - `renderDirector` in the code - that provides the Glimmer component with the content it should display. We also introduce an API for plugins to register a renderer for a notification type or override an existing one.
Some of the changes are partially extracted from https://github.com/discourse/discourse/pull/17379.
This will allow consumers to inject it using `topicTrackingState: service()` in preparation for the removal of implicit injections in Ember 4.0. `topic-tracking-state:main` is still available and will print a deprecation notice.
Ideally we would convert topic-tracking-state into a true service, rather than registering a model instance into the registry. However, inter-dependencies between service injections make this very difficult to achieve. We don't want to block Glimmer Component work, so this commit does the minimum for now.
When the route of the link is equal to the active route, we promote it
out of the "more..." links drawer and display it directly under the
community section. This commit fixes a bug where the secondary links in
the "more..." links drawer was not being marked as active.
Follow-up to e09fd7cde2
This commit extends the existing API bridge for supporting custom
general links in the old hamburger menu in Sidebar to support custom
footer links. Custom footer links can be added to the old hamburger
menu via the `api.decorateWidget("hamburger-menu:footerLinks")` API.
Footer links are added into the secondary section of the "More..." links
drawer in the Community section of the sidebar.
In the current hamburger menu dropdown, we have a link which allows users to toggle between mobile and desktop view on mobile and touch devices. This commit brings the same behaviour to sidebar.
