In the groups page (/g) where we list all the groups, we were only
showing one group "name" per group. If a full name was set, we would
show it, otherwise we would show the group's "display name".
This was somewhat inconsistent because we only show the group's names
in all the various controls we use to filter/search by group.
Plus we used a slightly different logic when displaying the names of a
group on the "group page".
So I updated the "GroupsInfo" component to show either 1 or 2 names
depending on whether a full name is set, and it's different from the
display name or the name of the group.
I used this component in the "group page" so the names will be
consistent between the "groups page" and the "group page".
Also renamed the "GroupsInfo" component to "GroupInfo" since it only
ever deals with 1 group at a time.
Ref - https://meta.discourse.org/t/-/345415
---
## When "full name" differs from the "group's name"
(cf. `@admins`, `@staff`, and `@moderators`)
<img width="1250" alt="Screenshot 2025-01-09 at 15 56 29"
src="https://github.com/user-attachments/assets/f8a0ecdd-2715-40d9-a1ed-26288f638d9f"
/>
## When "full name" is the same as the "group's name"
When `unicode` is allowed in usernames, then the group's full name is
the same as the group's name, so we only show one name.
<img width="1249" alt="Screenshot 2025-01-09 at 16 25 53"
src="https://github.com/user-attachments/assets/03438fbd-04f1-4672-91d5-bd6af2b32475"
/>
Following on from f369db5ae9, this change adds the ability to choose a custom locale to send to onebox providers.
If this setting is left blank, it will fall back to using default_locale.
3135f472e2 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.
This will cause the glimmer topic-list to be enabled for sites with compatible customizations. Incompatible customizations will print a deprecation message to the console, along with a link to more information.
Also cleans up a handful of specs/behaviour which were revealed by switching the default.
More details at https://meta.discourse.org/t/343404
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>
Create a basic config page that only contains developer-related settings, to replace the "developer" category view linked to from "Developer" in the admin sidebar.
* UX: Admin setting page consistency - Group permissions (#30528)
Followup c2282439b3 and
21470e4afd
Adds a new "Group permissions" page and group_permissions site
setting area, which shows every single group-based site setting
in the app and core plugins.
Also adds a "trust_levels" area to show on the already moved
admin "Trust level" settings page, since that previously was
showing a mix of trust level settings and allowed group settings.
* DEV: Review fixes
Create a basic config page that only contains navigation-related settings, to replace the setting filtered view linked to from "Navigation" in the admin sidebar.
Create a basic config page that only contains font-related settings, to replace the setting filtered view linked to from "Font style" in the admin sidebar.
The profile hiding feature is particularly problematic on sites that are
private (invite only or must approve users) so it is unconditionally disabled.
Also certain sites may prefer to disable the anti spam feature, they can
opt out using `hide_new_user_profiles`
Co-authored-by: Martin Brennan <martin@discourse.org>
This commit replaces the `full_name_required` setting with a new `full_name_requirement` setting to allow more flexibility with the name field in the signup form. The new setting has 2 options, "Required at signup" and "Optional at signup", which are equivalent to the true/false possibilities of the old setting, and a third option "Hidden at signup" that hides the name field from the signup form, making it effectively optional too.
New sites will have the "Hidden at signup" option as the default option, and existing site will continue to use the option that maps to their current configuration.
Internal topic: t/136746.
This setting suppresses topics and PMs from the admin UI unless they are participants. This is not a security feature: admins can always access all content on the site if needed.
This PR involves cleaning up the codebase from my (@keegangeorge's) todos.
In particular:
- Remove Form Template related todos (these are no longer in the roadmap)
- Remove old left-over AI summarization related code after moving to AI (https://github.com/discourse/discourse-ai/pull/658)
- Update one form template related spec
Setting tab should be added to permalinks so admins do not need to have left `/permalinks`.
A new component called `AreaSetting` was added to avoid duplications and
simplify adding settings to other sections.
We're changing the default of hide_email_address_taken to true. This is a trade-off we want to make, as it prevents account enumeration with minimal impact on legitimate users. If you forget you have an account and try to sign up again with the same e-mail you'll receive an e-mail letting you know.
This commit starts the rollout of the Glimmer post menu:
- default to `auto`: after the upgrade, it will be enabled on all discourse instances that do not have incompatible customizations
- unsilence the deprecation messages in the console
- removes the setting `glimmer_post_menu_groups` as it's no longer in the test phase
This is a follow-up to e6fdfcdcd2 which
did not remove the site setting from `config/site_settings.yml` and drop
the site setting value from the database.
It splits the hide_profile_and_presence user option and the default_hide_profile_and_presence site setting for more granular control. It keeps the option to hide the profile under /u/username/preferences/interface and adds the presence toggle in the quick user menu.
Co-authored-by: Régis Hanol <regis@hanol.fr>
This commit modernizes the post menu by migrating it from the existing widget-based implementation to Glimmer components. This transition aims to improve the maintainability, performance, and overall developer experience.
It also introduces a new DAG-based transformer API for customizations that aims to be more flexible than the widget base one.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
This commit switches the route for the about config page to retrieve the list of site settings that control the /about page by their area instead of their individual names.
Internal topic: t/136384.
The normalize_emails setting makes it so that only canonical e-mails are considered for validation purposes. This means disallowing "plus addressing". For example, with this enabled, bob@discourse.org and bob+foo@discourse.org are considered the same address, and you can only sign up with one of them.
Currently this is disabled by default, leading to a lot of spam sign-ups. It's healthier to consider this an opt-out setting.
This will allow admins to easily see all the experiments
in one place. In the future, we would like a full Experiments
config page with descriptions and screenshots, but this will
do for now.
Recently we added a new feature for automatically gridding images in the composer (https://github.com/discourse/discourse/pull/29260). After testing this feature under a setting for a short period of time, the feature is no longer experimental anymore.
This PR removes the site setting `experimental_auto_grid_images`.
This commit removes the feature flag for the new /about page, enabling it for all sites, and removes the code for old the /about page.
Internal topic: t/140413.
Followup 30fdd7738e
Adds a new site setting and corresponding user preference
to disable smart lists. By default they are enabled, because
this is a better experience for most users. A small number of
users would prefer to not have this enabled.
Smart lists automatically append new items to each
list started in the composer when enter is pressed. If
enter is pressed on an empty list item, it is cleared.
This setting will be removed when the new composer is complete.
This commit allows themes to define up to 2 screenshots
in about.json. These should be paths within the theme's
git repository, images with a 1MB max file size and max width 3840x2160.
These screenshots will be downloaded and stored against a theme
field, and we will use these in the redesigned theme grid UI.
These screenshots will be updated when the theme is updated
in the same way the additional theme files are.
For now this is gated behind a hidden `theme_download_screenshots`
site setting, to allow us to test this on a small number of sites without
making other sites make unnecessary uploads.
**Future considerations:**
* We may want to have a specialized naming system for screenshots. E.g. having light.png/dark.png/some_palette.png
* We may want to show more than one screenshot for the theme, maybe in a carousel or reacting to dark mode or color palette changes
* We may want to allow clicking on the theme screenshot to show a lightbox
* We may want to make an optimized thumbnail image for the theme grid
---------
Co-authored-by: Ted Johansson <ted@discourse.org>
