This commit updates the tests workflow to use the `discourse/discourse_test:release` image. This allows us to drop the some usage of Github actions cache which can be quite slow to fetch from our self hosted runners.
We are running on self hosted runners with more CPU and RAM so we should
be able to run one system test process per CPU core for more speedz.
This may lead to some instability in our system tests but it is hard to say unless we roll this change out. If it does lead to system tests being more unstable, we can easily roll back the change.
On our own self hosted runners, pulling from github actions cache is quite slow and can take up to 20 seconds for the `bundler cache` step. Instead, we will now copy the gems from the `/var/www/discourse/vendor/bundle` folder in the `discourse/discourse_test:release` image which is built daily. This eliminates the need to pull from Github actions cache and also potentially reduces our costs of cache storage.
Note that `discourse/discourse_test:release` is pulled periodically on our self hosted runners so there is no impact on the time it takes to initialize the container.
I think the log messages were used for initial production trials but the
log messages are actually not very useful in the grand scheme of things.
If the timing of the job is important information, one can get it by
enabling Sidekiq logging and obtain the information from there. There is
no need for us to flood the logs with these messages.
Also the messages will contain at most 100 ids so it is just alot of
noise in general.
We currently query the posts table without an order when notifying users of moved posts. Generally the query will return the lowest post number post (b/c ID correlates with post_number in most cases) but not always. This adds an order to the post query in notify_moved_posts job.
Also I removed some if statement nesting with early returns / guard clauses.
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? },
)
```
