This reverts commit 91e9c1c81343990d5ebbb3a3bb7c68ec4445d610.
After feedback, for now we are reverting this change. This is not
permanent, the settings sidebar will be removed again, after we:
* Visually group the settings the same way as the sidebar does
on All Settings
* Add more settings pages to the main admin sidebar to cover the ~250
settings not yet represented there
Currently, if creating an API key in "granular" mode, and not selecting any scopes, a globally scoped API key is created. This can be surprising and is not ideal. Having a key with no scopes isn't useful in the first place, so this PR adds client- and server side validations to check that at least one scope is selected if using "granular" mode.
In the current admin index page, all plugins show up as tabs. This includes plugins with auto-generated config routes.
This changes the tabs to include only plugins with custom UIs.
Before this commit it was complicated to render a `Checkbox` outside of
a `CheckboxGroup` as you would get no title, no description, no optional
hint and not tooltip.
This commits makes all of this possible by adding a special case for
checkboxes, and sharing code for tooltips and optional hint.
This commit also uses this opportunity to refactor part of the code to
use curryComponent and reduce code duplication.
This change adds a sidebar link for each plugin that fulfils the following criteria:
- Does not have an explicit admin route defined in the plugin.
- Has at least one site setting (not including enabled/disabled.)
That sidebar link leads to the automatically generated plugin show settings page.
This experiment hides the list of categories in the inner
sidebar for the main site settings page if the admin sidebar
is enabled. It also defaults the list of settings to "All"
instead of a specific category.
Our theory here is that people who use this page are using
it to find an exact setting, not to go through the categories
one by one. Our admin sidebar also has several groups of important
settings already too, so that can be used for browsing.
Finally, the input on the page focuses when you load it, so
filtering is faster.
This commit adds a new Localization config page for
admins, as a basic filtered site setting page similar
to Legal and Notifications. Included settings are:
* default locale
* allow user locale
* set locale from accept langauge header
* onebox locale
* display local time in user card
* discourse local dates enabled
* support mixed text direction
* unicode usernames
* allowed unicode username characters
FormKit allows you to set `@format` on a field which will set the width
of the wrapping container of the control. However, title and
descriptions are out of this container. FormKit will now by default
applies the same format to title and description.
You can override this behavior by using `@titleFormat` and
`@descriptionFormat`.
This commit converts the `AdminReport` component, which is quite
high complexity, to gjs. After this initial round, ideally this
component would be broken up into smaller components because it is
getting quite big now.
Also in this commit:
* Add an option to display the report description in a tooltip, which
was
the main way the description was shown until recently. We want to use
this on the dashboard view mostly.
* Move admin report "mode" definitions to the server-side Report model,
inside a `Report::MODES` constant, collecting the modes defined in
various
places in the UI into one place
* Refactor report code to refer to mode definitions
* Add a `REPORT_MODES` constant in JS via javascript.rake and refactor
JS to refer to the modes
* Delete old admin report components that are no longer used
(trust-level-counts, counts, per-day-counts) which were replaced
by admin-report-counters a while ago
* Add a new `registerReportModeComponent` plugin API, some plugins
introduce their own modes (like AI's `emotion`) and components and
we need a way to render them
All of these buttons use our default grey background styling, but aren't
carrying the `btn-default` class, which makes them easier to target in
themes. This PR adds the class.
We used this flag for experimenting with admin plugin sidebars. We have now settled on a tabbed layout, and this is no longer needed.
This PR simply ignores the flag in a backwards-compatible way, so we can discontinue usage in plugins and then remove the backwards-compatibility in core.
This fixes two minor problems on the admin webhooks page.
- Wrong key used for edit button title in listing.
- Duplicated use of `i18n` leading to "en.Edit" in show page.
Followup to 7fc8d74f3eed52116add452b5321b41e02e04499
We need to check that the user export data exists before creating a model, since having an empty model will cause the UI to incorrectly think there's a user export to display.
This change shows the correct message, instead.
The GDPR requires all users to be able to export their data, or request an export of their data. This is fine for active users as we have a data export button on user profiles, but suspended users have no way of accessing the data export function, and the workaround for admins to export data for suspended users involves temporarily unsuspending them, then impersonating the user to export the data as them.
Since suspended users no longer have access to their account, we can safely assume that the export request will be coming via a medium outside of Discourse (eg, email). This change is built with this workflow in mind.
This change adds a new "User exports" section to the admin user page, allowing admins to start a new export, and to download the latest export file.
This is a small clean-up PR that does the following:
- Convert api-keys.hbs to a RouteTemplate backed api-keys.gjs.
- Move the sub-page templates (index, show, new) into /api-keys sub-directory.
- Removes some styles that aren't used after the admin UI conversion.
* Fix tabbing inputs on first wizard step, the user would end up on
"Skip to content"
for the page "behind" the wizard. If the wizard is showing we can just
not render the skip to content element
* Only show the required wizard steps in the counter, so we do X/4
rather than X/6 at the top of the page.
* Change to "Setting up your theme..." by default, but if the install
takes 10s or more add a note that things are still happening and to
be patient.
Admin pages that are based off the customize or plugin templates were wrapped in the `admin-container` class, which has slightly different margins to the `admin-config-page` class, which is used on most admin pages.
This change ensures that all the admin pages have the same alignment.
Update the header of the admin Logs page to be more consistent with the rest of the admin UI.
The tabs to access the different sub-pages have also been updated.
Update the header of the admin Email Style page to be more consistent with the rest of the admin UI.
The HTML/CSS tabs have also been updated, which required an extra check being added to the NavItem component.
There are a few changes here to make the Emails admin page more consistent with the rest of the admin UI.
- The header and navigation menu have been updated.
- The sidebar now stays highlighted when visiting the email admin sub-pages.
- Moved the Template editor from /admin/customize/email_templates to /admin/email/templates, so it fit as a sub-page.
- Removed the link to the Template editor from the Customize section of the old top menu, since it's accessible from the Emails section, instead.
This change updates the header of the admin Components page to be more consistent with the rest of the admin UI.
The Themes and Components pages share the same templates, so this change switches the header based on which tab is active.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/(lib|utils)/*` into
`discourse/lib/*`, adds shims for the imports, and updates existing
uses in core.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/helpers/*` into
`discourse/helpers/*`, removes `discourse-common` from the Ember
resolver config, and adds shims for the imports.
Moves the theme component
https://github.com/discourse/discourse-review-ip-lookup into core, this
allows looking
up a user's IP directly from the review queue and seeing if
there are other users with the same IP on the forum
In #30096 we converted the API keys UI to follow the new admin UI guidelines.
During this conversion, the step where you get a chance to copy the API key after creating, was lost due to a rebase mistake.
This re-introduces it.
This commit finalises the admin setting page consistency
efforts by:
* Converting all route templates into .gjs
* Adding `@hideTabs={{true}}` for all the page headers so we
don't show a border line when it's not needed
* Introduce `@showBreadcrumb` and default to true for
AdminAreaSettings, for all these pages the Settings part of
the breadcrumb is redundant
3135f472e2c4221a9348aec27514d3e2947bc9ab added a nifty new FontSelector component, which creates a dropdown where each item is styled in the font that it corresponds to.
This change uses the new component to style the base_font and heading_font site setting selectors, too.
The chat emoji picker is renamed emoji-picker, and the old emoji-picker is removed.
This commit doesn't attempt to fully rework a new emoji-picker but instead tries to migrate everything to one picker (the chat one) and add small changes.
Other notable changes:
- all the favorite emojis code has been mixed into one service which is able to store one state per context, favorites emojis will be stored for all topics, and for each chat channel. Meaning that if you always use a specific emoji in a channel, it will only show as favorite emoji in this channel.
- a lot of static code has been removed which should improve initial load perf of discourse. Initially this code was around to improve the performance of the emoji picker rendering.
- the emojis are now stored, once the full list has been loaded, if you close and reopen the picker it won't have to load them again.
List of components:
- `<EmojiPicker />` will render a button which will open a dropdown
- `<EmojiPickerContent />` represents the content of the dropdown alone, it's useful when you want to render a picker from an action which is not the default picker button
- `<EmojiPickerDetached />` just a simple wrapper over `<EmojiPickerContent />` to make it easier to use it with `this.menu.show(...)`
---------
Co-authored-by: Renato Atilio <renatoat@gmail.com>
