In the absence of an opt-in to multiple specific languages in the
preferences, it makes more sense to filter by the user's presumed
language only (interface language or `lang` override)
When user has no locale preference saved (such as never changing it
from the default), the preferred posting language is nil, and
the dropdown is not visible
* Add database table for status-specific filters
* Add REST endpoints, entities and attributes
* Show status filters in /filters interface
* Perform server-side filtering for individual posts filters
* Fix filtering on context mismatch
* Refactor `toServerSideType` by moving it to its own module
* Move loupe and delete icons to their own module
* Add ability to filter individual posts from WebUI
* Replace keyword list by warnings (expired, context mismatch)
* Refactor server-side filtering code
* Add tests
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
- `GET /api/v1/admin/domain_allows` lists allowed domains
- `GET /api/v1/admin/domain_allows/:id` shows one by ID
- `DELETE /api/v1/admin/domain_allows/:id` deletes a given domain from the list
of allowed domains
- `POST /api/v1/admin/domain_allows` to allow a new domain:
if that domain is already allowed, the existing DomainAllow will be returned
* Add /api/v1/admin/domain_blocks
Fixes#18140
- `GET /api/v1/admin/domain_blocks` lists domain blocks
- `GET /api/v1/admin/domain_blocks/:id` shows one by ID
- `DELETE /api/v1/admin/domain_blocks/:id` deletes a given domain block
- `POST /api/v1/admin/domain_blocks` to create a new domain block:
if it conflicts with an existing one, returns an error with
an attribute `existing_domain_block` with the rendered domain block
* Simplify conflict handling as suggested in review
* Change unapproved and unconfirmed account to not be accessible in the REST API
* Change Account#searchable? to reject unconfirmed and unapproved users
* Disable search for unapproved and unconfirmed users in Account.search_for
* Disable search for unapproved and unconfirmed users in Account.advanced_search_for
* Remove unconfirmed and unapproved accounts from Account.searchable scope
* Prevent mentions to unapproved/unconfirmed accounts
* Fix some old tests for Account.advanced_search_for
* Add some Account.advanced_search_for tests for existing behaviors
* Add some tests for Account.search_for
* Add Account.advanced_search_for tests unconfirmed and unapproved accounts
* Add Account.searchable tests
* Fix Account.without_unapproved scope potentially messing with previously-applied scopes
* Allow lookup of unconfirmed/unapproved accounts through /api/v1/accounts/lookup
This is so that the API can still be used to check whether an username is free
to use.
* Fix warning an account outside of a report closing all reports for that account
* Make it clear what actions solve other reports
* Revert "Make it clear what actions solve other reports"
This reverts commit ad006de821f72e75480701298d13f0945b509059.
Calculate trends in temporary sets to avoid having to manage items
that go below the decay threshold while not having any moments
where a half-processed set is accessible to end-users
Eugen Rochko
Claire
Jeong Arm
Alexander Ivanov