* Add a limit to how many posts can get fetched as a result of a single request
* Add tests
* Always pass `request_id` when processing `Announce` activities
---------
Co-authored-by: nametoolong <nametoolong@users.noreply.github.com>
* Log admin approve and reject account
* Add unit tests for approve and reject logging
Co-authored-by: Francis Murillo <evacuee.overlap.vs3op@aleeas.com>
* Do not offer to mark statuses as sensitive if there is no undeleted status with media attachments
* Fix crash when marking statuses as sensitive while some statuses are deleted
Fixes#21910
* Fix multiple strikes being created for a single report when selecting “Mark as sensitive”
* Add tests
When a poll is edited, we reset the poll and remove all previous
votes. However, prior to this commit, the voter count on the poll
was not reset. This leads to incorrect percentages being shown in
poll results.
Fixes#21696
Co-authored-by: afontenot <adam.m.fontenot@gmail.com>
* Fix possible race conditions when suspending/unsuspending accounts
* Fix tests
Tests were assuming SuspensionWorker and UnsuspensionWorker would do the
suspending/unsuspending themselves, but this has changed.
* Fix trying to fetch posts from other users when fetching featured posts
* Rate-limit discovery of new subdomains
* Put a limit on recursively discovering new accounts
There is now a `norss` user preference for a user to opt out of having an RSS feed of their public posts. This operates on the exact same logic as the existing `noindex` for the search engine opt-out: the admin can check a box in Site Settings for a default setting for users. If a user has never touched their RSS opt-out setting then it is equal to whatever the default is. But individual users can override the default in their Preferences -> Other menu.
So a privacy-minded server admin could opt everyone out by default, but the overall default behavior is to have RSS feeds of public posts for everyone, which is the default Mastodon behavior anyway.
The `norss`, like `noindex`, is just a key on a pre-existing `settings` object that is a key-value store, so there doesn't even need to be a database migration for this!
Fixes#1232
* re-add the `article-type` class to article content in feed
* fix margin on `article-type`
* handle images where `src` is formatted like `/foo/bar.png` by inferring the protocol and domain (and port and password if applicable) from `url` in the AP object received -- without this we can't make a reasonable inference of origin since the domain for the content might be different from the domain of the activitypub server itself
Now when you make a call to `api/v1/preferences` you get a `posting:default:federation` response, which is `true` if the user's posts federate by default, and `false` if the user's posts are local-only by default.
This adds a `keep_local` column to the `account_statuses_cleanup_policy` table in the database. There is a new checkbox in the preferences for automatic post deletion, and when calculating which statuses to delete there is now a filter for `without_local_scope`.
This makes it so that when a user reports an account and selects "I don't like it", instead of getting a message about how they should personally block that person, it sends them to the normal reporting interface and they can file their report.
Fixes#1202