When passing a `plugins/...` path to bin/rspec, it's reasonable to assume that the developer wants the tests to be run with plugins loaded. This commit automatically takes care of that.
If `LOAD_PLUGINS` is explicitly specified, then that value will always be used.
This mimics the logic we already have for database migrations in the `bin/rake` stub
This setting suppresses topics and PMs from the admin UI unless they are participants. This is not a security feature: admins can always access all content on the site if needed.
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 makes the `contact_url` in the /about page behave as an absolute URL instead of a relative one if it doesn't explicitly start with a slash or a protocol. This prevents situation where, e.g., `www.example.com` is specified in the setting and the contact URL anchor tag ends up with a `href` that navigates to `<site address>/www.example.com` instead of just `www.example.com`. We prevent this by adding 2 leading slashes `//` to `contact_url` which makes the `href` resolves to the specified `contact_url` using the same protocol as the current site's.
Internal topic: t/143907.
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? },
)
```
When lurking on a Discourse as anonymous, if the sidebar is enabled, and a section contains only secondary links that are not visible to anonymous users, we should not display the "more..." button.
Otherwise it feels broken because clicking on it does nothing, since there are no "visible" links to be shown.
Internal ref t/144716
NOTE: I wasn't able to reproduce locally, so that's my best guess as to what happens based on the production error logs.
It's also the reason why I haven't changed/added any tests...
Earlier today, we started seeing a growing number of errors in the `register_presence_channel_prefix("chat-reply")` handler of the chat plugin.
It was all coming from a Discourse where they make a heavy use of chat channels. They create and **delete** category channels regularly.
If a user has a thread in one of the channels that just got deleted, the client application might not be aware (just yet), asks the server to be connected to the "presence" bus of that channel, and BOOOM.
The following [line](fa0ad0306c/plugins/chat/plugin.rb (L325)) explodes because `chat_channel` is `nil`
```ruby
config.allowed_group_ids = chat_channel.allowed_group_ids
```
And why is `chat_channel` `nil`? Because when we [do](fa0ad0306c/plugins/chat/plugin.rb (L319))
```ruby
chat_channel = Chat::Thread.find_by!(id: thread_id, channel_id: channel_id).channel
```
The thread is still in the database, but the associated channel has been deleted.
A proper fix would most likely be to delete all the `Chat::Thread` associated to a deleted `Chat::Channel` but this might have more technical & business implications.
* wip: return full name in /notifications.json
* DEV: test for full name
* DEV: add test for enable_names=true
* DEV: add notification6, cleanup
* DEV: fix tests
This PR involves cleaning up the codebase from my (@keegangeorge's) todos.
In particular:
- Remove Form Template related todos (these are no longer in the roadmap)
- Remove old left-over AI summarization related code after moving to AI (https://github.com/discourse/discourse-ai/pull/658)
- Update one form template related spec
Followup 203f93bcaffab1f493be70c2277ef11048f2017e
This commit makes sure the background for all the admin
site settings filters (including the filter input and
override checkbox) is consistent no matter what the theme,
as it currently changes based on theme.
* Split `shutdown` into two separate methods for better control:
- `shutdown` - signals threads to stop accepting new work
- `wait_for_termination` - waits for threads to finish (with optional timeout)
* Add tracking of busy threads via `@busy_threads` Set
* Make idle_time parameter optional with 30-second default
* Improve thread spawning logic:
- Spawn initial thread immediately when work is posted
- Spawn additional threads when all threads are busy and work is queued
* Fix race condition in work distribution
* Add busy thread count to stats output
* Add test coverage for zero min_threads configuration
This commit makes the ThreadPool more reliable, easier to use, and adds
better visibility into its internal state.
---------
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
