It is possible for admins to rename users like `system`
to some other username, but if they try to change it back
they cannot, since `system` is a reserved username.
This commit allows admins to change any user's username
to a reserved username _as long as that username is not
already in use_.
In the api docs note that `silence_reason` and `can_be_deleted` are
optional responses for the admin user api response.
Follow up to: 9cf78ba195
> TODO @blake / @sam - this is not passing cause "silence_reason" is a conditional attribute
> (also can_be_deleted is) - we need to figure out how to not include it in the schema - it is not included
> in the admin response by design
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>
This adds the Silence Reason column to silenced user lists.
This feature helps combat large spam attacks cause you can quickly see
why a user was silenced and then bulk act on all the silenced users
Our bulk report endpoint uses `hijack`, which does not
use the current user's locale via the `with_resolved_locale`
method in `ApplicationController`. This is happening because
we are doing `around_action` to set the locale, then calling
the code in the block inside the action directly when we use
`hijack`.
We can fix this by capturing `I18n.locale` when starting the
hijack then using `I18n.with_locale` when evaluating the
block inside `hijack`, this way the translations will always
use the correct locale based on the current user.
The customize routes add CSS classes that make these admin
config pages look different from the ones under /admin/config.
We want all config routes to be under /admin/config as well.
This commit moves the emoji, user fields, and permalinks pages
out of customize and into config, updating all references and
adding more rails routes as needed.
Also renames admin emojis route to emoji, emoji is singular and plural.
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.
Admins and moderators can see a user's deleted posts via the `/u/:username/deleted-posts` route. Admins can always see any post on the site, but that's not always the case for moderators, e.g., they can't see all PMs. So, this route accounts for that and excludes posts that a moderator wouldn't be allowed to see if they were not deleted.
However, there's currently a problem with that logic where admins who also have moderation privileges, are treated the same way as moderators and prevented from seeing posts that pure moderators can't see. This commit fixes that problem and only applies the permission checks to moderators who don't have admin privileges.
Internal topic: t/143107.
This commit adds the `add_request_rate_limiter` plugin API which allows plugins to add custom rate limiters on top of the default rate limiters which requests by a user's id or the request's IP address.
Example to add a rate limiter that rate limits all requests from Googlebot under the same rate limit bucket:
```
add_request_rate_limiter(
identifier: :country,
key: ->(request) { "country/#{DiscourseIpInfo.get(request.ip)[:country]}" },
activate_when: ->(request) { DiscourseIpInfo.get(request.ip)[:country].present? },
)
```
These controller tests are passing locally and in CI, but are failing the build when run in parallel.
I managed to recreate the failures by running the entire suite with turbo_spec and the right seed locally. After these changes, the parallel suite passes locally as well. 🤞
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.
Add flag reason filter and improve handling of deleted content in review queue
This commit enhances the review queue with several key improvements:
1. Adds a new "Reason" filter to allow filtering flags by their score type
2. Improves UI for deleted content by:
- Adding visual indication for deleted posts (red background)
- Properly handling deleted content visibility for staff (category mods can not see deleted content)
3. Refactors reviewable score type handling for better code organization
4. Adds tests for trashed topics/posts visibility
This change will help moderators more efficiently manage the review queue by
being able to focus on specific types of flags and better identify deleted
content.
The directory items controller specs that have a search param were not
matching how things worked in production. In a non-test environment the
UserSearch class depends on the `user_search_data` table being
populated, so the tests I corrected now use this table as well to match
reality.
Also added a new test to match the 20 user limit for search results that
currently exists. This 20 user limit is on the line between a bug and a
feature but it is how it is currently working so we should document
that. We have plans to increase this limit and it has been documented
here: https://meta.discourse.org/t/296485
This PR is a no-op and only changes the tests.
Co-authored-by: brrusselburg <25828824+brrusselburg@users.noreply.github.com>
In 806e37aaec, I improved the conflict handling when editing a post to account for title and tags.
This fixes an edge cases when a topic has a hidden tag the current editor can't see. When they submit their edit, we automatically add the hidden tags before checking with the tags stored in the database.
Reported in https://meta.discourse.org/t/341375
We've seen in some communities abuse of user profile where bios and other fields are used in malicious ways, such as malware distribution. A common pattern between all the abuse cases we've seen is that the malicious actors tend to have 0 posts and have a low trust level.
To eliminate this abuse vector, or at least make it much less effective, we're making the following changes to user profiles:
1. Anonymous, TL0 and TL1 users cannot see any user profiles for users with 0 posts except for staff users
2. Anonymous and TL0 users can only see profiles of TL1 users and above
Users can always see their own profile, and they can still hide their profiles via the "Hide my public profile" preference. Staff can always see any user's profile.
Internal topic: t/142853.
PostMover has a new option called freeze_original implemented in this commit. It was previously unexposed in the controller. This PR permits the param in the controller, and passes it into PostMover.
Also, this applies a value transformer for move/merge payload options. In addition a plugin outlet in the move post modal. This allows plugins to add content to the modal, which can modify the payload (and use the freeze_original argument for example)
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.
The hierarchical search for categories is composed of several complex
nested queries. This change ensures that the secured categories are
filtered out as soon as possible to ensure that the default limit of 5
categories is reached.
Without this fix, the search can return less than 5 categories if any
of the first 5 categories cannot be displayed due to permissions.
Sometimes changes to "What's new?" feed items are made or the feed items are
removed altogether, and the polling interval to check for new features is 1 day.
This is quite long, so this commit introduces a "Check for updates"
button for admins to click on the "What's new?" page which will bust
the cache for the feed and check again at the new features endpoint.
This is limited to 5 times per minute to avoid rapid sending of
requests.
Previously, the secure-upload redirection logic would fail for extension-less files. This commit updates it to work, and adds a spec for the behavior.
Extension-less file uploads are not allowed by default, so this is a very niche situation.
This commit introduces a new feature that allows staff to bulk select and delete users directly from the users list at `/admin/users/list`. The main use-case for this feature is make deleting spammers easier when a site is under a large spam attack.
Internal topic: t/140321.
This moves the logic of setting the correct permalink values back into the controller. And it replaces the validation with a simpler one, that always works, even when the model is loaded from the DB.
Follow-up to #29634 which broke import scripts and lots of documentation on Meta.
* FEATURE: Add skip notification option to group invite to topic
* DEV: rename `skip_notification` to `should_notify`
* DEV: update `should_notify` param to be default `true` in controllers
* DEV: update spec to use `greater than` instead of `equal to` to prevent flakiness
* Update app/controllers/topics_controller.rb
Co-authored-by: David Taylor <david@taylorhq.com>
* DEV: merged two `#invite_group` specs into one
* DEV: Added test case for `invite-group` in requests spec
---------
Co-authored-by: David Taylor <david@taylorhq.com>
Redesign the permalinks page to follow the UX guide. In addition, the ability to edit permalinks was added.
This change includes:
- move to RestModel
- added Validations
- update endpoint and clear old values after the update
- system specs and improvements for unit tests
Follow up to 6f8f6a7726
Prior to the linked commit, the `uploads#create` endpoint had a `upload_type` and `type` param that acted as aliases for each other and raised an error if both of them were missing. In the linked commit, we removed the `type` param and always required the `upload_type` param which break API consumers that only included `type` in their requests.
This commit adds back the `type` param temporarily and introduces a deprecation message for it so that API consumers are made aware of the eventual removal of the `type` param.
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 removes the new optimized category style introduced in
previous commits (d37a0d40, 9a80d718 and 430c42ac), in favour of the
existent `categories_only`.
When we added direct S3 uploads to Discourse, which use
presigned URLs, we never took into account the dualstack
endpoints for IPv6 on S3.
This commit fixes the issue by using the dualstack endpoints
for presigned URLs and requests, which are used in the
get-presigned-put and batch-presign-urls endpoints used when
directly uploading to S3.
It also makes regular S3 requests for `put` and so on use
dualstack URLs. It doesn't seem like there is a downside to
doing this, but a bunch of specs needed to be updated to reflect this.
