This switches the signup/login UI to the full page experience by
default. This has been in use by many sites for multiple months and we
have ironed out many fixes in the meantime.
The `full_page_login` setting is also marked for removal in about
1.5mths, by the end of April 2025.
We didn't have support in the #problem constructor for multiple targets, forcing developers to manually construct a Problem instance. This involves a lot of details and is error prone.
This PR supports passing an optional target argument to the constructor. This will be passed on to the translation_data method to generate the correct message as well.
This PR renames a couple of settings related to anonymous mode:
1. `allow_anonymous_posting` → `allow_anonymous_mode`. This setting is
used as a switch for the entire anonymous mode feature, so it makes
sense to give it a generic name that better reflects what the setting
does.
2. `allow_anonymous_likes` → `allow_likes_in_anonymous_mode`. The new
name is clearer and will match a new setting that we'll add to allow
anonymous users to post in chat.
Internal topic: t/148088.
This improves the new rake task to bulk delete posts based on feedback:
- Honour the `can_permanently_delete` site setting.
- Fix a warning about a scope order no being applied due to batching.
- Fix an issue where double delete would result in duplicate user
histories.
Currently, when converting raw hotlinked image urls to image upload
markdown, the `alt` attribute is left blank.
This change sets the `alt` to the original filename (which means it will
also appear in the lightbox).
This adds more context and accessibility to the image and is consistent
with how regular uploaded images default to use the filename.
For example:
`http://foo.bar/screenshot.jpg` becomes
``
This change ensures that queued posts that have ended up in the review queue due to matched a watched word display correctly.
It also improves the data checking to ensure that any other reviewables with watched words don't break the review queue, either.
This PR adds a destroy:posts rake task that can be used to hard-delete a list of posts. Useful for dealing with large amounts of spam that has been soft deleted and needs to go.
Notes:
Works on both non-deleted and soft-deleted posts. (We might want to change this to work on only soft-deleted posts?)
Works exclusively on post IDs. We can't mix topic and post IDs as they might clash, and we have no way of resolving that ambiguity.
Accepts either a rake-style array of IDs or, more conveniently, you can pipe the argument in through STDIN.
Added a confirmation step since it's a fairly destructive operation.
Previously, the SiteSetting::Update service allowed to update of a
single site setting. In the About controller, we were using the loop
through all settings -
https://github.com/discourse/discourse/blob/main/app/controllers/admin/config/about_controller.rb#L39
It is suboptimal because if the 3 first settings are saved and the
fourth is invalid, we will end with partially updated data.
Changing SiteSetting::Update to accept hash means that we will check
upfront if none of the settings are hidden or invalid and update all or
none.
Custom policies are used to report which settings are failing.
When `revoke_ungranted_titles!` was invoked, the optional list of
`user_ids` was not passed from the argument list to the query. This
resulted in an exception because the placeholder `:user_ids` existed in
the query.
This sets the stage for being able to consolidate Like notifications
using full names. It also is crucial to this [Reactions plugin
PR](https://github.com/discourse/discourse/pull/31292).
The Like consolidation PR will come after these.
This commit changes the display of category hashtag
autocomplete to show the parent category name in this
format:
* Parent Name > Child Name
This helps further distinguish categories in the autocomplete
where there may be multiple different parent categories with
the same name child category, e.g. if every category has an
Announcements subcategory.
This commit updates the `Jobs::BadgeGrant` scheduled job to enqueue on
`Job::BackfillBadge` regular job for each enabled badge on the site.
The rationale for this change is that we started seeing the
`Jobs::BadgeGrant` job taking hours on sites with lots of enabled badges
as well as users because the job was backfilling all enabled badges
serially within the job. This is bad as it means that a `mini_scheduler`
thread is tied up
by this job thus reducing the overall capacity of `mini_scheduler` for
hours.
When we initially turned on admin sidebar for new sites,
existing sites had the value set to -1. We need to show
the problem check to these sites too, but currently it only
checks if `admin_sidebar_enabled_groups` is empty.
Lazy loading images naturally causes a slight delay, because the browser
only starts to load them after laying out the DOM and checking whether
they're in the viewport. Plus, in Safari, re-rendering the DOM of a
lazy-loaded image always causes a brief flicker, even if the image is
already cached in the browser.
Lazy-loading is most beneficial on large one-off images which are often
rendered outside the viewport. That's frequently the case for images
which users share in topics. Avatars, on the other hand, are very small
images, they're very often above-the-fold, and the same avatar often
occurs many times on the same page.
Therefore, this commit removes `loading="lazy"` from avatars, which
should improve avatar load times in all browsers, and stop the flicker
in Safari.
---
Tapping logo to reload topic-list in Safari. Before: https://github.com/user-attachments/assets/242299f8-aa13-4991-b321-2f143603ed26
After: https://github.com/user-attachments/assets/5e5bfd28-3a78-40fd-af21-3d92e7b3ba8a
We want to avoid surprises when we make the new admin sidebar baseline, so in addition to announcements, we're also adding a problem check that informs you if you don't have it enabled for any group yet.
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.
Previously when attempting to edit a globally shadowed setting, the
error message was not very helpful, it said "You are not allowed to
change hidden settings". This commit changes the error message to
reflect the actual problem, which is that the setting is shadowed by
a global setting via ENV var.
This patch replaces the parameters provided to a service through
`params` by the contract object.
That way, it allows better consistency when accessing input params. For
example, if you have a service without a contract, to access a
parameter, you need to use `params[:my_parameter]`. But with a contract,
you do this through `contract.my_parameter`. Now, with this patch,
you’ll be able to access it through `params.my_parameter` or
`params[:my_parameter]`.
Some methods have been added to the contract object to better mimic a
Hash. That way, when accessing/using `params`, you don’t have to think
too much about it:
- `params.my_key` is also accessible through `params[:my_key]`.
- `params.my_key = value` can also be done through `params[:my_key] =
value`.
- `#slice` and `#merge` are available.
- `#to_hash` has been implemented, so the contract object will be
automatically cast as a hash by Ruby depending on the context. For
example, with an AR model, you can do this: `user.update(**params)`.
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
Toggle the button to enable the experimental site setting from "What's new" announcement.
The toggle button is displayed when:
- site setting exists and is boolean;
- potentially required plugin is enabled.
Creating or updating flags generates global side effects. Sometimes it
seems the state can leak from the flag specs.
This is probably related to the use of `fab!`. This patch replaces those
calls with standard `let`s. While the overall performances of these
tests will be a little less good, their state should not leak anymore.
* Add migrations to ensure password hash is synced across users & user_passwords
* Persist password-related data in user_passwords instead of users
* Merge User#expire_old_email_tokens with User#expire_tokens_if_password_changed
* Add post deploy migration to mark password-related columns from users table as read-only
* Refactored UserPassword#confirm_password? and changes required to accommodate hashing the password after validations
If you have the admin dashboard open, and one of the admin notices listed has already been dismissed (e.g. in another tab, or by another admin) we would show an ugly "FAILED" modal.
This change makes the admin dismiss endpoint idempotent. If the admin notice is already destroyed, then respond with 200. This will also correctly remove it from the list in the front-end.
This will help to enforce a consistent pattern for creating service
actions.
This patch also namespaces actions and policies, making everything
related to a service available directly in
`app/services/<concept-name>`, making things more consistent at that
level too.
his is a new feature that lets admins dismiss notices from the dashboard. This helps with self-service in cases where a notice is "stuck", while we work on provisions to prevent "sticking" in the first place.
- fetch models inside services
- validate `user_id` in contracts
- use policy objects
- extract more logic to actions
- write specs for services and action
* add data migration to keep only unexpired or most recently expired user password
* refactor to 1:1 relationship between User and UserPassword
* add migration to remove redundant indexes on user passwords
In this PR we introduced a new setting `enforce_second_factor_on_external_auth` which disables enforce 2FA when the user is authenticated with an external provider.
https://github.com/discourse/discourse/pull/27506
However, with the first registration with an external provider, we authenticate the user right after activation. In that case, we need to also keep information that the user was authenticated with an external OAuth provider.
We need a way to disable certain checks programatically, e.g. on Discourse hosting. This PR adds a configuration option for this, and makes it so that disabled checks aren't run as part of #run_all.
Currently the push_notification_time_window_mins is set to 10
minutes by default. We want to change this to 1 minute, which is the
delay it has been set to on meta and our internal site already for over
a year now.
This conforms to the expectation users have that notifications are
delivered close to immediately.
This change ensures native push notifications respect the site setting for push_notification_time_window_mins. Previously only web push notifications would account for the delay, now we can bring more consistency between Discourse in browser vs Hub, by applying the same delay strategy to both forms of push notifications.
We support a low-level construct called "inline checks", which you can use to register a problem ad-hoc from within application code.
Problems registered by inline checks never show up in the admin dashboard, this is because when loading the dashboard, we run all realtime checks and look for problems. Because of an oversight, we considered inline checks to be "realtime", causing them to be run and clear their problem status.
To fix this, we don't consider inline checks to be realtime, to prevent them from running when loading the admin dashboard.
There is a bug with chat type flags - "An error occurred: Applies to is not included in the list"
Flag.valid_applies_to_types is a set of core types and types registered by plugins `Set.new(DEFAULT_VALID_APPLIES_TO | DiscoursePluginRegistry.flag_applies_to_types)`
Using lamba should ensure that valid values are calculated dynamically.
Our old group SMTP SSL option was a checkbox,
but this was not ideal because there are actually
3 different ways SSL can be used when sending
SMTP:
* None
* SSL/TLS
* STARTTLS
We got around this before with specific overrides
for Gmail, but it's not flexible enough and now people
want to use other providers. It's best to be clear,
though it is a technical detail. We provide a way
to test the SMTP settings before saving them so there
should be little chance of messing this up.
This commit also converts GroupEmailSettings to a glimmer
component.
