* Fix error responses in `from` search prefix (addresses mastodon/mastodon#17941)
Using unsupported prefixes now reports a 422; searching for posts from an
account the instance is not aware of reports a 404. TODO: The UI for this
on the front end is abysmal.
Searching `from:username@domain` now succeeds when `domain` is the local
domain; searching `from:@username(@domain)?` now works as expected.
* Remove unused methods on new Error classes as they are not being used
Currently when `raise`d there are error messages being supplied, but
this is not actually being used. The associated `raise`s have been
edited accordingly.
* Remove needless comments
* Satisfy rubocop
* Try fixing tests being unable to find AccountFindingConcern methods
* Satisfy rubocop
* Simplify `from` prefix logic
This incorporates @ClearlyClaire's suggestion (see
https://github.com/mastodon/mastodon/pull/17963#pullrequestreview-933986737).
Accepctable account strings in `from:` clauses are more lenient than
before this commit; for example, `from:@user@example.org@asnteo +cat`
will not error, and return posts by @user@example.org containing the
word "cat". This is more consistent with how Mastodon matches mentions
in statuses. In addition, `from` clauses will not be checked for
syntatically invalid usernames or domain names, simply 404ing when
`Account.find_remote!` raises ActiveRecord::NotFound.
New code for this PR that is no longer used has been removed.
* Fix /api/v1/admin/accounts
Compatibility was broken since #17009 which changed the underlying filter class
without changing the controller.
This commits restore support for the old parameters.
* Add /api/v2/admin/accounts with the new parameters
* Add tests
* Add missing filter for `silenced` status
Co-authored-by: Eugen Rochko <eugen@zeonfederated.com>
Co-authored-by: Eugen Rochko <eugen@zeonfederated.com>
Conflicts:
- `README.md`:
Upstream updated copyright year, we don't mention it so kept our version.
- `app/controllers/admin/dashboard_controller.rb`:
Not really a conflict, upstream change (removing the spam checker) too close
to glitch-soc changes. Ported upstream changes.
- `app/models/form/admin_settings.rb`:
Same.
- `app/services/remove_status_service.rb`:
Same.
- `app/views/admin/settings/edit.html.haml`:
Same.
- `config/settings.yml`:
Same.
- `config/environments/production.rb`:
Not a real conflict, upstream added a default HTTP header, but we have
extra headers in glitch-soc.
Added the header.
Conflicts:
- `README.md`:
Our README.md files are completely different. Discarded upstream changes.
- `app/javascript/core/admin.js`:
Updating rails-ujs, no real conflict, but a comment to close to changed
code. Various glitch-soc-only files have been updated to match those changes,
though.
- `package.json`:
No real conflict, just an additional dependency in glitch-soc that was too
close to something updated upstream. Took upstream's changes.
Conflicts:
- `app/controllers/api/v1/statuses_controller.rb`:
Conflict due to upstream adding a new parameter (with_rate_limit),
too close to glitch-soc's own additional parameter (content_type).
Added upstream's parameter.
- `app/services/post_status_service.rb`:
Conflict due to upstream adding a new parameter (rate_limit),
too close to glitch-soc's own additional parameter (content_type).
Added upstream's parameter.
- `app/views/settings/preferences/appearance/show.html.haml`:
Conflict due to us not exposing theme settings here (as we have
a different flavour/skin menu).
Took upstream change, while still not exposing theme settings.
- `config/webpack/shared.js`:
Coding style fixes for a part we have rewritten.
Discarded upstream changes.
Conflicts:
- Gemfile
- app/controllers/api/v1/search_controller.rb
Conflict because we changed the number of default results to be
configurable
- app/lib/settings/scoped_settings.rb
Addition of a new “noindex” site-wide setting,
conflict due to our change of the two other site-wide settings
(default flavour and skin instead of theme)
- spec/controllers/application_controller_spec.rb
Addition of a new “noindex” site-wide setting,
conflict due to our change of the two other site-wide settings
(default flavour and skin instead of theme)
* Add type, limit, offset, min_id, max_id, account_id to search API
Fix#8939
* Make the offset work on accounts and hashtags search as well
* Assure brakeman we are not doing mass assignment here
* Do not allow paginating unless a type is chosen
* Fix search query and index id field on statuses instead of created_at
