This commit adds a new admin UI under the route `/admin-revamp`, which is
only accessible if the user is in a group defined by the new `enable_experimental_admin_ui_groups` site setting. It
also adds a special `admin` sidebar panel that is shown instead of the `main`
forum one when the admin is in this area.
We also add an "Admin Revamp" sidebar link to the community section, which
will only appear if the user is in the setting group:
Within this there are subroutes defined like `/admin-revamp/config/:area`,
these areas could contain any UI imaginable, this is just laying down an
initial idea of the structure and how the sidebar will work. Sidebar links are
currently hardcoded.
Some other changes:
* Changed the `main` and `chat` panels sidebar panel keys to use exported const values for reuse
* Allowed custom sidebar sections to hide their headers with the `hideSectionHeader` option
* Add a `groupSettingArray` setting on `this.siteSettings` in JS, which accepts a group site setting name
and splits it by `|` then converts the items in the array to integers, similar to the `_map` magic for ruby
group site settings
* Adds a `hidden` option for sidebar panels which prevents them from showing in separated mode and prevents
the switch button from being shown
---------
Co-authored-by: Krzysztof Kotlarek <kotlarek.krzysztof@gmail.com>
These updates significantly improve IDE tooling for imports across the Discourse core codebase, and also for framework packages. The `@types/ember-*` packages are a temporary solution until we get onto Ember 5, which ships its types in the main package.
The previous approach of having jsconfig files in each package directory did work, but once you start adding all the possible interlinks between them, we hit the file count limit of VSCode's tooling (because it counts every file for every jsconfig its referenced in). Having one file at the root means that a single file can apply to all core packages and plugins.
Long-term, to get the same functionality for all themes/plugins, we may need to look at building/publishing a Discourse types package which can be added to theme/plugin package.json files for development purposes.
As of #23867 this is now a real package, so updating the imports to
use the real package name, rather than relying on the alias. The
name change in the package name is because `I18n` is not a valid
name as NPM packages must be all lowercase.
This commit also introduces an eslint rule to prevent importing from
the old I18n path.
For themes/plugins, the old 'i18n' name remains functional.
This reverts commit 5f0bc4557f.
Through extensive internal discussion we have decided to revert
this change, as it significantly impacted moderation flow for
some Discourse site moderators, especially around "something else"
flags. We need to re-approach how flags are counted holistically,
so to that end this change is being reverted.
We'll probably have to keep the globals around for compatibility, but we should always import it ourselves. We'll followup with an updated eslint config to enforce this.
`escape` from `pretty-text/sanitizer` is a re-export of the same
function defined in `discourse-common`. Updating the import paths
across the codebase to use the `discourse-common` import path.
`escape` is a rather simple function that can be accomplished with
a regular expression in `discourse-common`.
On the other hand, the remaining parts in `pretty-text/sanitizer`
has a lot of code, PLUS it depend on the rather heavy "xss" NPM
library.
Currently, most of the consumers of `pretty-text/sanitizer` are of
the `{ escape }` varient. This is resolved by this PR.
The remaining usages are either:
1. via/through `PrettyText` which is essentially gated behind
loading the markdown-it bundle, OR
2. via `sanitize` from `discourse/lib/text`
I believe we may ultimately be able to move all the usages to behind
the markdown-it bundle (or, equivilantly, set up another lazy bundle
for `sanitize`) and be able to shed the sanitization code and the
"xss" library from the initial page load.
`discourse/lib/text` also defines a `sanitizeAsync` which is gated
behind loading the markdown-it bundle.
Looking through the usages of `sanitize`, I believe most of these
can be safely switched to use `sanitizeAsync`, in that they are
already in an asynchrnous path that handles a server response. Most
of them are actually rendering a piece of server-generated HTML
message as flash message, so I am not sure there really is value in
sanitizing (we should be able to trust our own server?), but in any
case, code-wise, they should already be able to absorb the async
just fine.
I am not sure if `sanitize` and `sanitizeAsync` are actually API
compatible – they both take `options` but I think those `options` do
pretty different things. This is somethign for another person to
investigate down the road in another PR.
According to `all-the-plugins`, `discourse-graphviz` also import
from this location, so perhaps we should PR to update. That being
said, it doesn't really hurt anything to keep the alias around for
a while.
For the admin plugin list we want to be able to link to
a meta topic for plugins, but we have no standard way to
do this at the moment. This adds support for meta_topic_id
alongside other plugin metadata like authors, URL etc,
that gets built into a Meta topic URL in the serializer.
Currently, if you set an integer site setting in the admin interface and include thousands separators, you will silently configure the wrong value.
This PR replaces TextField inputs for integer site settings with NumberField. It also cleans the numeric input of any non-digits in the backend in case any separators make it through.
Regression from https://github.com/discourse/discourse/pull/23668 where we stopped passing in `this.badgeReason` to the badge granting function. This PR fixes that and adds a unit test to cover that code path.
1. actually call `popupAjaxError`, thanks :P
2. don't close a modal on error
3. use `extractError()` instead of manually joining error messages
4. …or passing just the error object to `this.flash`
Our custom implementation of `getOwner` includes a fallback which returns an owner, even if the passed object does not have one set. This is confusing and creates a false sense of security. Generally if the fallback is used, it means there is a problem with the patterns being used.
This commit renames our custom implementation to `getOwnerWithFallback`, while maintaining the old `getOwner` export with a deprecation notice. Core code is updated to use the official `@ember/application` implementation, or the new `getOwnerWithFallback` function.
This commit updates all core uses of `{ getOwner } from discourse-common/lib/get-owner` to use `getOwnerWithFallback`. Future commits will work through and convert many of these to use the official `@ember/application` implementation
DEV: Adjust site setting search limiter
This opens up the site setting search limiter some more so that when
searching for "min length" it will contain
"min_personal_message_post_length" as one of the results, but not open
it up so much so that when searching for "digest",
"pending_users_reminder_delay_minutes" won't show up in the results
because it isn't really related.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
- Switch to `@tracked` and native getters
- Remove queryParam defaults which are awkward to work with. Instead, add `resolvedBlah` getters
- Add 'no results found' text
- Use standard 'model' key instead of a custom `setupController` method
- Remove use of `route-action`
- Remove `{{action` helper
Default queryParams in ember controllers are tricky to work with, especially when combined with the new router service. Instead, we can handle defaults ourselves
* DEV: upgrade grant badge modal to glimmer
* DEV: add unit tests for grant badge utils
* DEV: replace grant-badge-controller mixin with grant-badge-utils in admin-user-badges controller
* DEV: remove GrantBadgeController mixin
1. Use `this.` instead of `{{action}}` where applicable
2. Use `{{fn}}` instead of `@actionParam` where applicable
3. Use non-`@` versions of class/type/tabindex/aria-controls/aria-expanded
4. Remove `btn` class (it's added automatically to all DButtons)
5. Remove `type="button"` (it's the default)
6. Use `concat-class` helper
This tab doesn't really provide anything useful, and can be quite
confusing in some cases. Each plugin is already listed below, and
you can navigate to their settings from there. We want to move away
from the catch-all Plugins category for site settings. Core plugins are
not shown in this list as at 97a812f022.
This commit contains a few improvements:
* Use LinkTo instead of a button with a weird action referencing the
controller to navigate to the filtered settings for a plugin
* Add an AdminPlugin model with tracked properties and use that when
toggling the setting on/off and in the templates
* Make it so the Settings button for a plugin navigates to the correct
site setting category instead of always just going to the generic
"plugins" one if possible
Martin Brennan
dependabot[bot]
David Taylor
Godfrey Chan
Krzysztof Kotlarek
Ted Johansson
Kelv
Arpit Jalan
Kris
Jarek Radosz
Blake Erickson
Renato Atilio
Isaac Janzen
Jeff Wong
Vinoth Kannan
Meghna