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
DEV: Display fuzzy site setting search results below direct matches
When searching for site settings, in the results under the ALL category
all the fuzzy search results were showing first followed by any direct
matches. This change adjusts that so that fuzzy searches show below
direct matches.
Fuzzy results are now also sorted based on their gap calculation in
ascending order.
Sometimes the fuzzy search would return too many site setting results
making it hard to find what you are searching for. This change still
allows for fuzzy searching but tightens up the criteria for being a
fuzzy match.
One example is searching for 'cheer', a term associated with a plugin,
previously returned ~55 search results. With this change it will return
~13 (Actual numbers depend on how many plugins your instance has).
Another example is searching for 'digest'. Previously returned ~37
results and now will return ~14.
Follow up to: e63e193a0a
See also: https://meta.discourse.org/t/276013
Previously, we had a `showFooter` boolean on the application controller which would be set true/false in various routes by different routes/controllers. A global `routeWillChange` hook would set it `false` before every route transition, and the destination route/controller would have to set it `true` for the footer to show correctly.
This commit replaces that with a new 'declarative' system. Instead of having to set the value true/false manually, UIs which need the footer to be hidden can simply include the `{{hide-application-footer}}` helper in their template when needed. The helper/service will automatically keep track of all the current invocations of that helper, and only show the footer when there are 0 invocations.
This significantly simplifies things, and removes the need for many observers and controller injections, both of which are considered 'code smells' in modern Ember applications.
In this commit 2.5 years ago, variables for showOnUserCard and showOnProfile were removed, but we still used them in the component. e29605b
This corrects the variable names and adds a test to confirm the text is now shown.
This commit makes some visual tweaks to the admin panel plugin list, and introduces functional 'toggle switches' for admins to enable/disable plugins more easily.
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
FEATURE: Only approved flags for post counters
* Why was this change necessary?
The counters for flagged posts in the user's profile and user index from
the admin view include flags that were rejected, ignored or pending
review. This introduces unnecessary noise. Also the flagged posts
counter in the user's profile includes custom flags which add further
noise to this signal.
* How does it address the problem?
* Modifying User#flags_received_count to return posts with only approved
standard flags
* Refactoring User#number_of_flagged_posts to alias to
User#flags_received_count
* Updating the flagged post staff counter hyperlink to navigate to a
filtered view of that user's approved flagged posts to maintain
consistency with the counter
* Adding system tests for the profile page to cover the flagged posts
staff counter
provide the ability to edit theme settings in the json editor, and also copy them as a text file so they can be pasted into another instance.
Reference: /t/65023
- Convert `admin-incoming-email` modal to component-based API
- Testing that the modal was working in local development was extremely challenging due to the need for `rejected` and `bounced` emails. Something that is not easy to stub in a local dev environment. To make this process more smooth for future developers I have added a new rake task:
```
desc "Creates sample email logs"
task "email_logs:populate" => ["db:load_config"] do |_, args|
DiscourseDev::EmailLog.populate!
end
```
That will generate fully functional email logs in development to be toyed with.
<img width="787" alt="Screenshot 2023-07-20 at 3 27 04 PM" src="https://github.com/discourse/discourse/assets/50783505/47b3fe34-cd7e-49a5-8fe6-768c0fbd1aa2">
The gjs/gts formats are a new pattern for authoring Ember components. This commit introduces support for these patterns to our build pipeline for core/plugins, and converts a handful of components to use the new format. It also introduces relevant updates to our linting config, and to our sample vscode configuration.
Co-authored-by: Godfrey Chan <godfreykfc@gmail.com>
Co-authored-by: Krystan HuffMenne <kmenne+github@gmail.com>
Since 0fa92529ed, helpers can now be implemented as plain JS functions. This makes them much easier to write/read, and also makes them usable in `<template>` gjs files.
