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 b3fa335c7d
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
* 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 4d32635c69.
* 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 02bebb7e91 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.
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
