* FIX: Wizard improvements post-merge part 1
Followup 3135f472e2c4221a9348aec27514d3e2947bc9ab
Fixes the following:
* On mobile, the Styling step was very narrow
* When clicking Next on the Styling step after previously
selecting Hot, we got an error
Also makes the following UX improvements for the preview:
* Use different topic titles for Latest and Hot
* Also make Hot view and reply numbers higher
This helps differentiate the two previews.
* DEV: Review fixes
Followup c2282439b32d879a73217eec62449f042914d7d0
Make the Files and Other config pages reached from the sidebar
use our consistent site setting page rules.
Also slightly improves AdminAreaSettings so we don't show
"Settings not found" when still loading settings.
When inserting anything from the chat composer dropdown, any popups opened weren't properly focussed.
This was due to the default behaviour of the dropdown menu closing, which tries to return the focus to the original triggering element. This would normally be the correct behaviour, but here we want the menu to close in the background, handing focus off to the popup, instead.
Create a basic config page that only contains Onebox-related settings, to replace the "onebox" category view linked to from "Onebox" in the admin sidebar.
Create a basic config page that only contains user API-related settings, to replace the "user_api" category view linked to from "User API" in the admin sidebar.
Create a basic config page that only contains rate limiting-related settings, to replace the "rate_limits" category view linked to from "Rate limits" in the admin sidebar.
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.
Create a basic config page that only contains security-related settings, to replace the "security" category view linked to from "Security settings" in the admin sidebar.
Followup 3187606d3402003437c2ccd6121a26f874939228
Fix full_name_requirement INSERT by adding ON CONFLICT DO NOTHING,
on sites that already have this setting this migration will fail.
Create a basic config page that only contains security-related settings, to replace the "security" category view linked to from "Security settings" in the admin sidebar.
Back then in 31e31ef, we added the Content-Disposition headers so that SVGs get downloaded instead of get run in the browser. Inadvertently, this also causes other attachments like pdfs and videos to be downloaded instead of heeding the "Open in new tab" option that users choose in the browser.
When the header is removed, the default value is "inline", this allows the browser to perform as requested. This also applies to other file types like pdfs, allowing users to "Open in new tab" and view them in the browser instead of always downloading them.
Existing tests (#10205) already do check that SVGs remain downloaded. Some existing tests written for PDFs have been modified to cater for SVGs instead, when there was a bug in defining the filenames per #10108
Followup c2282439b32d879a73217eec62449f042914d7d0
Make the Experimental config page reached from the sidebar
use our consistent site setting page rules.
Experimental "What's new?" feature feed items previously calculated
a boolean for experimentEnabled on the client based on the siteSettings
service, and this would control the initial state of the experiment
toggle.
However this requires the person who creates the site setting for the
experiment to remember to set it to `client: true`. This commit removes
that manual step by calculating whether the experiment is enabled
server-side, where we have access to all the site settings.
* 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.
