This feature allows admins to find what they are
looking for in the admin interface via a search modal.
This replaces the admin sidebar filter
as the focus of the Ctrl+/ command, but the sidebar
filter can also still be used. Perhaps at some point
we may remove it or change the shortcut.
The search modal presents the following data for filtering:
* A list of all admin pages, the same as the sidebar,
except also showing "third level" pages like
"Email > Skipped"
* All site settings
* Themes
* Components
* Reports
Admins can also filter which types of items are shown in the modal,
for example hiding Settings if they know they are looking for a Page.
In this PR, I also have the following fixes:
* Site setting filters now clear when moving between
filtered site setting pages, previously it was super
sticky from Ember
* Many translations were moved around, instead of being
in various namespaces for the sidebar links and the admin
page titles and descriptions, now everything is under
`admin.config` namespace, this makes it way easier to reuse
this text for pages, search, and sidebar, and if you change it
in one place then it is changed everywhere.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
Followup to 087e8e4bdb53f71930ec5c930c463c37dd2bd58d
- Fixes the variable-prefixer so it doesn't explode when the input is
unparseable
- Add URL polyfills so that postcss can print its errors properly
- Catch postcss errors in the same way as sass errors
This replaces the password validation mixin with a helper class in the
password-reset controller class.
Also removes the redundant flag `passwordValidationVisible` that is
already fully dependent on whether `passwordValidation` has a `reason`.
This introduces a helper class for password validation logic, and
replaces the mixin in the signup controller class. All properties that
impact password validation in that class are also converted to
autotracked ones.
This change adds a new `type_source` field to the `Reviewable` model, indicating whether the Reviewable type was registered by `core`, a plugin, or an `unknown` source.
When a plugin that registered a Reviewable type is disabled, this allows us to tell the user which plugin they need to re-enable to handle any orphan reviewable items.
The `toggle-summary` class is specific to our use in the AI plugin, so
I've moved it there in
https://github.com/discourse/discourse-ai/pull/1136...
This wrapper was occupying some space even though it was empty in the PM
topic map, so it's better to not have it.
This also allows us to remove some sub-optimal CSS that was adding a gap
based on content within it. Without the empty wrapper, we can always
have the gap present.
This commit improves a few aspects regarding group name validation:
- `min_username_length` and `max_username_length` are validated with the
shortest and longest names of users and groups
- skip validation of the group name when the group is an automatic one
This mode was introduced briefly in 2019, and allowed editing theme
settings/translations/extra-css from the admin panel UI. But then we
decided that making it possible to edit these fields via the UI
conflicted with our recommendation of using a proper IDE,
discourse_theme, and version-controlled themes. The feature was disabled
in core, and theme-creator uses a monkey-patch to expose it.
Even for the current use in theme creator, there are now major styling
and functionality issues, because this feature is not visible or tested
in core. For example: it doesn't allow editing 'extra JS' fields, which
are arguably the most common.
This commit removes the code for this 'advanced' mode, in advance of
some more extensive modernization of this component/model.
When `revoke_ungranted_titles!` was invoked, the optional list of
`user_ids` was not passed from the argument list to the query. This
resulted in an exception because the placeholder `:user_ids` existed in
the query.
This sets the stage for being able to consolidate Like notifications
using full names. It also is crucial to this [Reactions plugin
PR](https://github.com/discourse/discourse/pull/31292).
The Like consolidation PR will come after these.
`consolePrefix()` is an expensive operation (it throws a synthetic
error, then parses the backtrace), so we should only do it when
absolutely necessary
On the topic-list page, this provides a 3-4% improvement in "init to
render" times.
Follows up: https://github.com/discourse/discourse/pull/31107
This PR replaces the use of the UsernameValidation mixin with the helper
class for the InvitesShowController and CreateAccount modal component,
and deletes the mixin.
Permalink search regressed in
https://github.com/discourse/discourse/pull/30633 where the search
implementation was changed from server side to client side. Prior to
that change, we included a `filter` param in the request to make the
server find permalinks that matched the given filter and return the
results limited to 100 records. However, with that change, we stopped
sending the `filter` param with the request, which made the server
always return the same 100 records which would then be filtered on the
client side. That means if a site has more than 100 records, any records
that don't make it in the first 100 will never be found using search.
Meta topic:
https://meta.discourse.org/t/permalinks-no-longer-has-a-way-to-search-or-show-all-permalinks/351922?u=osama
Followup to 310cd513d88e3670c7008682ae4b35414084a17d. The `uploadDone`
callback returns the whole upload object, so we need to extract the URL
from it in these cases.
The current code was doing:
- initial value for `showPreview`
- setting another default value in `_setupPreview`
The fix is to move all the computation in one initial step when
initializing the property.
This changes makes relative date formats consistent for both tiny and
medium formats.
Previously we were removing 12 hours from the date for medium format
when it was more than 2520 minutes (42 hours) but not for tiny date
formats.
- Switch to use new `<DecoratedHtml` component (including
`renderGlimmer` support)
- Updates click handling to use `{{on` modifier instead of manual event
listener setup/teardown
- Remove JQuery
- Move decoration into `components/post-item`, instead of managing it
from the top-level user-stream component
- Use new `DecoratedHtml` component
This commit allows admins to filter the list of feature
feed items on the "What's new?" page to _only_ show experiments.
This is useful to both find existing experiments they may have
enabled, and to get a better overview of new ones they would
like to try.
This will eventually not be required when we build a dedicated
config page for experiments.
```
WARNING: Sass's behavior for declarations that appear after nested
rules will be changing to match the behavior specified by CSS in an upcoming
version. To keep the existing behavior, move the declaration above the nested
rule. To opt into the new behavior, wrap the declaration in `& {}`.
More info: https://sass-lang.com/d/mixed-decls
```
Related:
40fd82e2d1
This PR introduces three new plugin modifiers attached to
- `basic_post_serializer.cooked`
- `basic_topic_serializer.fancy_title`
- `topic_view_serializer.fancy_title`
Implementation note: I had wanted to add them in the `Post` and `Topic`
models themselves, but they do not directly provide access to the
request's scope which is needed for the use case.
This fixes the destination of the auth process in the following
scenarios:
- when landing on a PM or a topic as an anonymous user and then loggin
in
- when landing on a public topic, hitting Reply or Like and then logging
in
Eventually, this new component will be used everywhere that we render
'decorated' HTML (e.g. all posts and chat messages). It takes the best
bits from our main widget-based post rendering and re-creates it in a
more ember-native way. For example:
- The HTML is first rendered in a detached DOM, so that requests for
images/iframes/etc. are not triggered until after the decoration
- HTML generation and decoration is done in a helper (i.e. during the
'render' phase of the runloop). I think that's the 'most Ember
compatible' way for us to do this. It means that components added via
`renderGlimmer` will be rendered in the same runloop, and it means that
things like `schedule("afterRender")` will work exactly as expected.
- HTML will be re-rendered and re-decorated whenever the `@html` or
`@decorate` arguments change
- BUT, `untrack` is used to ensure that reactive state accessed inside
the decorate function will not trigger a re-render. This is mostly for
compatibility with existing decorators, and we may want to make
reactivity opt-in in future
- A self-contained `renderGlimmer` system is included. This will allow
`helper.renderGlimmer` to be used for any content in these components.
Implementing it in a self-contained way rather than using the service
means that the component will work ok in unit tests, and that rendered
components will show up in the right place in the Ember inspector.
This commit only introduces the new component in DiscourseBanner.
Followups will introduce it elsewhere.
Ember workaround to ensure that a field with the same name is correctly
destroyed/created when changing the params and then correctly calling
registerField/unregisterFIeld.
