Conflicts:
- `README.md`:
Upstream changed their README, we have our own.
Kept ours.
- `app/helpers/application_helper.rb`:
Minor code style fix upstream, on a line that is different in glitch-soc
due to the different theming system.
Applied the code style fix to our own code.
- `app/views/settings/preferences/appearance/show.html.haml`:
Code style fix on a line next to lines exclusive to glitch-soc.
Applied upstream changes.
- `yarn.lock`:
Upstream updated a dependency textually close to a glitch-soc-only
dependency.
Updated the dependency like upstream did.
Conflicts:
- `.prettierignore`:
Upstream added a line at the end of the file, while glitch-soc had its own
extra lines.
Took upstream's change.
- `CONTRIBUTING.md`:
We have our custom CONTRIBUTING.md quoting upstream. Upstream made changes.
Ported upstream changes.
- `app/controllers/application_controller.rb`:
Upstream made code style changes in a method that is entirely replaced
in glitch-soc.
Ignored the change.
- `app/models/account.rb`:
Code style changes textually close to glitch-soc-specific changes.
Ported upstream changes.
- `lib/sanitize_ext/sanitize_config.rb`:
Upstream code style changes.
Ignored them.
Conflicts:
- `.github/dependabot.yml`:
Upstream made changes while we have dropped this file.
Keep the file deleted.
- `.prettierignore`:
Upstream made changes at the end of the file, where we
had our extra lines.
Just moved our extra lines back at the end.
- `app/serializers/initial_state_serializer.rb`:
Upstream code style changes.
Applied them.
- `app/services/backup_service.rb`:
Upstream code style changes.
Applied them.
Conflicts:
- `.prettierignore`:
Upstream added a line at the end, glitch-soc had extra entries at the end.
Added upstream's new line before glitch-soc's.
- `Gemfile.lock`:
Upstream updated dependencies while glitch-soc has an extra one (hcaptcha).
Updated dependencies like upstream did.
- `app/controllers/api/v1/statuses_controller.rb`:
Not a real conflict, upstream added a parameter (`allowed_mentions`) where
glitch-soc already had an extra one (`content_type`).
Added upstream's new parameter.
- `app/javascript/styles/fonts/roboto-mono.scss`:
A lot of lines were changed upstream due to code style changes, and a lot
of those lines had path changes to accomodate glitch-soc's theming system.
Applied upstream's style changes.
- `app/javascript/styles/fonts/roboto.scss`:
A lot of lines were changed upstream due to code style changes, and a lot
of those lines had path changes to accomodate glitch-soc's theming system.
Applied upstream's style changes.
Conflicts:
- `README.md`:
Minor upstream change, our README is completely different.
Kept ours.
- `lib/tasks/assets.rake`:
glitch-soc has extra code to deal with its theming system,
upstream changed a line that exists in glitch-soc.
Applied upstream changes.
Conflicts:
- `.github/workflows/build-image.yml`:
Upstream updated `docker/build-push-action`, and we a different config
for `docker/metadata-action` so the lines directly above were different,
but it's not a real conflict.
Upgraded `docker/build-push-action` as upstream did.
- `app/javascript/mastodon/features/compose/components/compose_form.js`:
Upstream changed the codestyle near a line we had modified to accommodate
configurable character count.
Kept our change.
Conflicts:
- `config/i18n-tasks.yml`:
Upstream added new ignored strings, glitch-soc has extra ignored strings
because of the theming system.
Added upstream's changes.
* Fix /api/v1/admin/trends/tags using wrong serializer
Fix regression from #18641
* Only use `REST::Admin::TagSerializer` when the user can `manage_taxonomies`
* Fix admin trending hashtag component to not link if `id` is unknown
* Allow changing hide_collections setting with the api
This is currently only possible with app/controllers/settings/profiles_controller.rb
and is the only difference in the allowed parameter between the two controllers
* Fix the lint issue
* Use normal indent
Conflicts:
- `README.md`:
Discarded upstream changes: we have our own README
- `app/controllers/follower_accounts_controller.rb`:
Port upstream's minor refactoring
Conflicts:
- `app/models/concerns/domain_materializable.rb`:
Fixed a code style issue upstream in a PR that got merged in glitch-soc
earlier.
Changed the code to match upstream's.
Conflicts:
- `.github/workflows/build-image.yml`:
Upstream changed how docker images were built, including how
they were cached.
I don't know much about it, so applied upstream's changes.
- `app/controllers/admin/domain_blocks_controller.rb`:
The feature, that was in glitch-soc, got backported upstream.
It also had a few fixes upstream, so those have been ported!
- `app/javascript/packs/admin.js`:
Glitch-soc changes have been backported upstream. As a result,
some code from `app/javascript/core/admin.js` got added upstream.
Kept our version since our shared Javascript already has that feature.
- `app/models/user.rb`:
Upstream added something to distinguish unusable and unusable-because-moved
accounts, while glitch-soc considers moved accounts usable.
Took upstream's code for `functional_or_moved?` and made `functional?`
call it.
- `app/views/statuses/_simple_status.html.haml`:
Upstream cleaned up code style a bit, on a line that we had custom changes
for.
Applied upstream's change while keeping our change.
- `config/initializers/content_security_policy.rb`:
Upstream adopted one CSP directive we already had.
The conflict is because of our files being structurally different, but the
change itself was already part of glitch-soc.
Kept our version.
Conflicts:
- `app/views/admin/announcements/edit.html.haml`:
Upstream change too close to theming-related glitch-soc change.
Ported upstream changes.
- `app/views/admin/announcements/new.html.haml`
Upstream change too close to theming-related glitch-soc change.
Ported upstream changes.
Conflicts:
- `app/models/account.rb`:
Conflict because we (glitch-soc) have disabled trending of posts without
review.
Discarded that upstream change.
- `app/views/admin/settings/discovery/show.html.haml`:
Just an extra setting in glitch-soc.
Kept that extra setting.
Conflicts:
- `app/models/custom_emoji.rb`:
Not a real conflict, just upstream changing a line too close to
a glitch-soc-specific validation.
Applied upstream changes.
- `app/models/public_feed.rb`:
Not a real conflict, just upstream changing a line too close to
a glitch-soc-specific parameter documentation.
Applied upstream changes.
Conflicts:
- `app/javascript/mastodon/features/compose/components/poll_form.js`:
glitch-soc change because of having changed the default number of
available poll options.
Applied upstream's changes while keeping glitch-soc's default number of
poll options.
- `public/oops.png`:
We had a minor graphics change, probably not worth diverging from upstream.
Took upstream version.
Conflicts:
- `app/javascript/mastodon/locales/ja.json`:
Upstream change too close to a glitch-soc-specific string.
The glitch-soc-specific string should not have been in this file, so it
has been moved to `app/javascript/flavours/glitch/locales/ja.js`.
- `app/javascript/packs/public.js`:
Upstream refactored a part, that as usual is split and duplicated in various
pack files. Updated those pack files accordingly.
- `app/views/layouts/application.html.haml`:
Upstream fixed custom.css path in a different way than we did, went with
upstream's change.
* Change featured tag updates to add/remove activity
* Fix to check for the existence of feature tag
* Rename service and worker
* Merge AddHashtagSerializer with AddSerializer
* Undo removal of sidekiq_options
* Add LIMIT of featured tag to instance API response
* Add featured_tags_collection_url to Account
* Add synchronization of remote featured tags
* Deliver update activity when updating featured tag
* Remove featured_tags_collection_url
* Revert "Add featured_tags_collection_url to Account"
This reverts commit cff349fc27b104ded2df6bb5665132dc24dab09c.
* Add hashtag sync from featured collections
* Fix tag name normalize
* Add target option to fetch featured collection
* Refactor fetch_featured_tags_collection_service
* Add LIMIT of featured tag to v1/instance API response
Cherry-picked d2528b26b6
Conflicts:
- `app/serializers/initial_state_serializer.rb`:
Upstream changed stuff, we had extra attributes.
Applied upstream changes while keeping our extra attributes.
- `app/serializers/rest/instance_serializer.rb`:
Upstream actually moved that to `app/serializers/rest/v1/instance_serializer.rb`,
so updated that file by keeping our extra attributes, and took upstream's
version of `app/serializers/rest/instance_serializer.rb`.
- `spec/views/about/show.html.haml_spec.rb`:
Took upstream's version.
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)
Conflicts:
- `app/controllers/home_controller.rb`:
Upstream made it so `/web` is available to non-logged-in users
and `/` redirects to `/web` instead of `/about`.
Kept our version since glitch-soc's WebUI doesn't have what's
needed yet and I think /about is still a much better landing
page anyway.
- `app/models/form/admin_settings.rb`:
Upstream added new settings, and glitch-soc had an extra setting.
Not really a conflict.
Added upstream's new settings.
- `app/serializers/initial_state_serializer.rb`:
Upstream added a new `server` initial state object.
Not really a conflict.
Merged upstream's changes.
- `app/views/admin/settings/edit.html.haml`:
Upstream added new settings.
Not really a conflict.
Merged upstream's changes.
- `app/workers/scheduler/feed_cleanup_scheduler.rb`:
Upstream refactored that part and removed the file.
Ported our relevant changes into `app/lib/vacuum/feeds_vacuum.rb`
- `config/settings.yml`:
Upstream added new settings.
Not a real conflict.
Added upstream's new settings.
Conflicts:
- `app/controllers/settings/preferences_controller.rb`:
Upstream dropping `digest` from notifications emails while we have more
notification emails settings.
Removed `digest` from our list while keeping our extra settings.
- `app/javascript/packs/admin.js`:
Conflicts caused by glitch-soc's theming system.
Applied the changes to `app/javascript/core/admin.js`.
- `app/views/settings/preferences/other/show.html.haml`:
Upstream removed a setting close to a glitch-soc-only setting.
Applied upstream's change.
* 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
The constraint was applied prior to decoding, and rejected anything containing
the '%' character, which would be used for anything with non-ASCII unicode
characters.
- `.env.production.sample`:
Our sample config file is very different from upstream since it is much more
complete. Upstream added documentation for a few env variables.
Copied the new variables/documentation from upstream.
- `app/lib/feed_manager.rb`:
Upstream added a timeline type (hashtags), while glitch-soc already had an
extra one (direct messages). Not really a conflict but textually close
changes.
Ported upstream's changes.
- `app/models/custom_emoji.rb`:
Upstream upped the custom emoji size limit, while glitch-soc had configurable
limits.
Upped the default limits accordingly.
- `streaming/index.js`:
Upstream reworked how hastags were normalized. Minor conflict due to
glitch-soc's handling of instance-local posts.
Ported upstream's changes.
Conflicts:
- `app/controllers/admin/base_controller.rb`:
Minor conflict caused by glitch-soc's theming system.
- `app/javascript/mastodon/initial_state.js`:
Minor conflict caused by glitch-soc making use of max_toot_chars.
- `app/models/form/admin_settings.rb`:
Minor conflict caused by glitch-soc's theming system.
- `app/models/trends.rb`:
Minor conflict caused by glitch-soc having more granular
notification settings for trends.
- `app/views/admin/accounts/index.html.haml`:
Minor conflict caused by glitch-soc's theming system.
- `app/views/admin/instances/show.html.haml`:
Minor conflict caused by glitch-soc's theming system.
- `app/views/layouts/application.html.haml`:
Minor conflict caused by glitch-soc's theming system.
- `app/views/settings/preferences/notifications/show.html.haml`:
Minor conflict caused by glitch-soc having more granular
notification settings for trends.
- `config/navigation.rb`:
Minor conflict caused by glitch-soc having additional
navigation items for the theming system while upstream
slightly changed every line.
Conflicts:
- `.github/workflows/build-image.yml`:
Fix erroneous deletion in a previous merge.
- `Gemfile`:
Conflict caused by glitch-soc-only hCaptcha dependency
- `app/controllers/auth/sessions_controller.rb`:
Minor conflict due to glitch-soc's theming system.
- `app/controllers/filters_controller.rb`:
Minor conflict due to glitch-soc's theming system.
- `app/serializers/rest/status_serializer.rb`:
Minor conflict due to glitch-soc having an extra `local_only` property
* 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
Conflicts:
- `app/javascript/styles/fonts/montserrat.scss`:
Code style changes upstream, path changes in glitch-soc.
Applied upstream's code style changes.
- `app/javascript/styles/fonts/roboto-mono.scss`:
Code style changes upstream, path changes in glitch-soc.
Applied upstream's code style changes.
- `app/javascript/styles/fonts/roboto.scss`:
Code style changes upstream, path changes in glitch-soc.
Applied upstream's code style changes.
- `app/models/account.rb`:
Textual conflict only caused by glitch-soc using a different value
for character limits in a nearby line.
Applied upstream's changes.
- `app/views/statuses/_simple_status.html.haml`:
Attribute added to a tag modified by glitch-soc.
Added upstream's attributes.
- `yarn.lock`:
Upstream added/updated dependencies close to glitch-soc-only ones.
Updated/added upstream dependencies.
* 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.
Conflicts:
- `package.json`:
Not really a conflict, upstream updated a dependency textually adjacent to a
glitch-soc-only one.
Updated the dependency as upstream did.
Conflicts:
- `Gemfile.lock`:
Not a real conflict, just an upstream dependency udpated
textually too close to a glitch-soc-only dependency.
Updated dependencies like upstream.
- `app/controllers/settings/preferences_controller.rb`:
Upstream added settings where we had extra glitch-soc-specific settings.
Added upstream's new settings.
- `app/models/user.rb`:
Upstream added settings where we had extra glitch-soc-specific settings.
Added upstream's new settings.
- `config/i18n-tasks.yml`:
Not a real conflict, just a new upstream line too textually close to
a glitch-soc-only line.
Ported upstream's change.
Conflicts:
- `app/controllers/concerns/sign_in_token_authentication_concern.rb`:
Upstream removed this file, while glitch-soc had changes to deal with
its theming system.
Removed the file like upstream did.
Fixes#17898
Since #17204, the admin API has only been available through the web
application because of the unconditional requirement to provide a valid CSRF
token.
This commit changes it back to `null_session`, which should make it work
both with session-based authentication (provided a CSRF token) and with a
bearer token.
* 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>
Matt Jankowski
Claire
Christian Schmidt
Nick Schonning
Eugen Rochko
Carl Schwan
nametoolong
Francis Murillo
trwnh
James Tucker
prplecake
Takeshi Umeda
tateisu