This reverts commit 0b10e335ae.
I realised that some of these actions are overridden in themes/plugins, so this is going to cause problems (especially because modifyClass doesn't currently work well with the `@action` decorator)
This makes it more obvious what's happening, and makes it much less likely that users will send repeated reset emails (and thereby hit the rate limit)
Followup to e97ef7e9af
Even when the admin sidebar sections are collapsed, they should expand while filtering. When the filter is removed, sections should go back to the previous state.
In addition, trim whitespace from the filter section.
Only remaining ones are `routes/discourse.js` and `routes/application.js`. Those two both contain legacy `actions: {}` hashes which need to be updated before being converted to native class syntax.
This commit removes the `/admin-revamp` routes which were introduced as a part of an experiment to revamp the admin pages. We still want to improve the admin/staff experience, but we're going to do them within the existing `/admin` routes instead of introducing a completely new route.
Our initial efforts to improve the Discourse admin experience is this commit which introduces the foundation for a new subroute `/admin/config` which will house various new pages for configuring Discourse. The first new page (or "config area") will be `/admin/config/about` that will house all the settings and controls for configuring the `/about` page of Discourse.
Internal topic: t/128544
This commit re-introduces the "Move to Inbox" and "Move to Archive"
bulk topic actions, which we had in the old modal but had not yet added
to the new "experimental" dropdown, which isn't really experimental at
this point.
Once this is merged we can remove the old modal and only
rely on the new dropdown.
The issue was simple, we were just not returning the helper in the `user-private-messages` controller which was preventing any action to happen.
Follow up: we should write specs for this toggle.
Prior to this fix we were opening a modal before closing the `DMenu` modal, given `DModal` expects only one modal at a time it was closing the latest modal and instantly closing the one we just opened.
This adds a small indicator of the Ctrl+/ shortcut that
exists for the admin sidebar filter, since it's not very
obvious that you can do that. This should help people
who are struggling with the long list of links -- it's
much faster to use the keyboard and search for what
you are looking for.
Followup 73c6bb2593
The admin sidebar was also disappearing on another
child admin route (in this case the docker_manager
plugin update page). Instead of relying on the route
name which is flaky, we can set a boolean when the
sidebar is forced in the root admin route, then
turn it off when leaving admin.
When uploading a video, the composer will now show a thumbnail image in
the composer preview instead of just the video placeholder image.
If `enable_diffhtml_preview` is enabled the video will be rendered in
the composer preview and is playable.
Delay rendering sidebar sections after sidebar is shown
Showing the popup takes about 100ms, then rendering each section
could take up to and additional 200ms, which leaves the total just
outside of 300ms. If we cheat by rendering the popup first then
the sections in the next frame, it improves our paint time
Introduce DeferredRender to encapsulate 'paint later'
This uses a new nav style with the heirarchy:
```
Breadcrumbs
|- Title
|- Description
|- Third-Level Navigation
```
The navigation bar uses the transparent red-underlined
buttons similar to the user activity page.
Over time all admin pages will use this, but this starts
with the new plugin show page.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
We need to register a waiter so that `settled()` will wait for `runAfterFramePaint()` callbacks to be run before proceeding.
Re-lands 63b7b598cb, but wrapped with `isTesting()` to avoid production errors.
# Context
We currently have a tracked value of `topic` in the header service that we utilize across the app for determining the presence of a topic.
A simple example is: If you are in a topic, and scroll down the page, we need to communicate to the header that a topic is present and we change the styling of the header.
The issue with this logic is that when entering a topic (and you are at the top of the page), we **haven't** set the topic on the header service yet. We only set the topic when you have scrolled down on the page (set by `app/components/discourse-topic.js`)
This is unhelpful behavior when you are utilizing a plugin outlet that is receiving the `topic` from the header:
17add599e3/app/assets/javascripts/discourse/app/components/header/topic/info.gjs (L85)
As the `topic` won't be present until you scroll down the page.
# Changes
This PR adds a tracked `inTopic` value to the header service that is a boolean value. This is to let the app know
> Yes, we are scrolled within a topic
And instead sets the tracked `topic` value immediately, if you are loading a topic, to allow the necessary data to be populated to the plugin outlets on page load.
