* UX: Admin setting page consistency - Group permissions (#30528)
Followup c2282439b32d879a73217eec62449f042914d7d0 and
21470e4afd49127fc6281a5bde6357e86b11a4ae
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
The `faker` gem, which is a dependency for the `*:populate` rake tasks, isn't installed in the production environment, so we should only load files/classes related to those rake tasks in non-production environments.
This version number is a technical detail that controls
what items show up on certain sites, most admins don't
need this level of detail. Remove it here, maybe we can
add it back in some hidden way later if needed.
Related to 5a55c9062a
The chat plugin now makes use of the plugin API that was added in the linked commit for extending the reviewables:populate rake task.
* UX: Update email and security sidebar link copy
Followup b3fa335c7db3b92530625cbe37db32427f567ebc
Changes these sidebar links to better reflect
what these pages contain:
* (Email) Server setup → Server setup & logs
* (Security) Staff action logs → Logs & screening
* DEV: Test fix
Followup 8d5c4ecc3398611764a4459c0e92f0fb90edd90f
Implement review suggestions from https://github.com/discourse/discourse/pull/30541
after merge, and also fix other hardcoded strings on this
dashboard.
* FEATURE: default value to fields in automation
This PR adds the property `extra.default_value` to the fields in automation. This property is used to set the default value of the field.
Reducing the nil checks we have to do in automation fields.
I've added only testing in the `da-choices-field-test.js` file, but we could add tests to all the fields.
* FEATURE: Add trigger_on option to `topic_tags_changed` automation
This new field will allow users to specify when the trigger should be fired. The options are:
- `tags_added_or_removed`: The trigger will be fired when tags are added or removed from the topic.
- `tags_added`: The trigger will be fired when tags are added to the topic.
- `tags_removed`: The trigger will be fired when tags are removed from the topic.
This PR also brings a migration to set the `trigger_on` field to `tags_added_or_removed` for all existing `topic_tags_changed` automations.
* DEV: reorganize the specs in context blocks
* DEV: migration to add trigger_on field default value to topic_tags_changed_trigger
* DEV: `down` migration for `add_trigger_on_field_default_value_to_topic_tags_changed_trigger` migration
* Update plugins/automation/lib/discourse_automation/triggers/topic_tags_changed.rb
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
* Update plugins/automation/config/locales/client.en.yml
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
* DEV: lint files and update topic_tags_changed trigger to use `default_value`
* Revert "FEATURE: default value to fields in automation"
This reverts commit 4d32635c695b1da36dbe3343bb55c223a720106a.
* DEV: remove migration file
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
For mentions within threads, the mentioned user can experience a stuck notification. This is due to thread memberships only being created for users who interact with a thread. Without the membership we cannot track if the message containing the mention was read by the user.
The solution to this explored in this PR is:
- auto add memberships for mentioned users (only direct mentions for performance reasons).
- update channel/thread unread queries to check notification read status AND thread membership last read message id when counting mentions.
Previously the mention count would remain until the user notification (containing the mention) was read. However this only happens if the user clicks the notification or clicks dismiss all notifications. When a user navigated to the thread without clicking the notification, the green/urgent badge on chat would remain even after a hard page refresh.
topic-navigation and topic-map appear in the DOM before the post stream, and are then rearranged with CSS grid. That means that, if they are entirely within the viewport, and does not have a fixed/sticky position, then they will be chosen as the browser's scroll anchor point.
We never want these elements to be used as the anchor, so we can set `overflow-anchor: none`.
https://meta.discourse.org/t/344386/16
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.
This change expands the matcher added in 02bebb7e9152996d86b980baea73eacb5d9222ef to include plugin `settings.yml` files as requiring a server restart when they change.
The `Listen.to(only: ...)` filter only matches against filenames (as opposed to full paths) so we can't add a matcher against `plugins/.*/config/settings.yml` to make it explicit.
Our self hosted runners are limited in quantity so we should preserve
them for workflows that actually require the additional resources
instead of tying them up on workflows that do not benefit from the
additional resources.
Followup c2282439b32d879a73217eec62449f042914d7d0
Make the trust levels config page reached from the sidebar
use our consistent site setting page rules.
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.
This PR moves the logic from the setting-object mixin to a helper class. I've opted to maintain the interface of the previous classes (ThemeSettings / SiteSetting) that used the mixed-in methods through aliases so that we limit the amount of changes here (these are referenced in the string form and across classes/templates).
Another option we may consider in future if we want to optimize for performance is straight duplication which would trade off this overhead of aliasing/chaining calls through the helper for some duplicate code - only 2 models require these methods at the time of this PR.
site_settings.yml is read when the server starts, but isn't re-read if it changes. (Eg, adding a new setting, or changing the configuration of an existing setting.)
This change includes site_settings.yml as a file that requires a server restart when it changes. This behaviour obeys the AUTO_RESTART environment variable.
We already had isIpadOS, but for some themes and components
we really need to do different things if the user is on
a tablet, including Android tablets.
isTablet and isTabletScreen have been introduced to the
capabilities service.
isTablet is true if the screen size is a tablet, touch
is detected, or we have already detected iPad OS, or
the device matches tablet UAs
isTabletScreen checks both portrait and landscape dimensions
of 1280x600 which should cover most cases.
Follow-up to 3187606d34
When the `enable_names` setting is false and the `full_name_requirement` setting is set to `required_at_signup`, the name field in the signup form should effectively be not required (and hidden). However, that is not actually the case at the moment because the `name-validation.js` mixin only checks for the `full_name_requirement` setting when determining whether the name field should block a new signup.
This commit fixes the issue by making the `full_name_required_for_signup` and `full_name_visible_in_signup` site attributes check for the `enable_names` setting themselves. This spares any consumers of these properties from having to remember to include a check for the `enable_names` setting.
With the previous logic, autocompletes were being opened mid-word, which was annoying and didn't properly work – selecting an option would generate an invalid format, mixing existing with new.
This PR makes a simple change: only ever trigger an autocomplete on word ends, and close them when arrow-navigating out of the word-end boundary.
ref /t/-/143169
