Conflicts:
- `app/views/admin/custom_emojis/new.html.haml`:
Upstream split some `simple_form` arguments across multiple lines.
One of the arguments in glitch-soc was different.
Split as upstream's did, keeping our different limit argument.
- `app/views/admin/settings/appearance/show.html.haml`:
Upstream split some `simple_form` arguments across multiple lines.
Glitch-soc had a different field because of the different theming
system.
Kept glitch-soc's definition of that form field.
Conflicts:
- `config/initializers/content_security_policy.rb`:
Upstream reworked the CSP, we kept our version for now.
- `spec/requests/content_security_policy_spec.rb`:
Upstream reworked the CSP, we kept our version for now.
Conflicts:
- `app/models/form/admin_settings.rb`:
Upstream added the notion of overriden settings, while we had extra code for
pseudo-settings (only used to combine flavour and skin in a single select
field).
Ported upstream changes.
- `config/i18n-tasks.yml`:
Upstream added `simple_form.overridden` to `ignore_unused`,
we had `simple_form.glitch_only`.
Added `simple_form.glitch_only` as well.
Conflicts:
- `.github/workflows/build-image.yml`:
Upstream entirely refactored this, while we changed the docker repository
to upload to and disabled the “latest” tag.
Applied the repository change to `.github/workflows/build-*.yml`, as well
as disabling native ARMv64 builds.
- `README.md`:
We have a completely different README.
Kept ours.
- `app/views/admin/settings/shared/_links.html.haml`:
Upstream refactored, we had an extra item.
Refactored as upstream did.
- `spec/controllers/api/v1/timelines/public_controller_spec.rb`:
Upstream deleted this file, to be replaced by a request spec at
`spec/requests/api/v1/timelines/public_spec.rb`.
We had an extra bit about enabling the public timelines because we have
different defaults than upstream.
Moved that bit to `spec/requests/api/v1/timelines/public_spec.rb`
Conflicts:
- `app/views/admin/settings/appearance/show.html.haml`:
Upstream enforced an uniform code style around lambdas, and glitch-soc
had a different lambda due to its theming system.
Applied the same code style changes.
- `app/views/settings/preferences/appearance/show.html.haml`:
Upstream enforced an uniform code style around lambdas, and glitch-soc
removed some code just after the lambda.
Applied the same code style changes.
Conflicts:
- `app/controllers/auth/confirmations_controller.rb`:
Upstream merged our captcha code, but there are some
conflicts due to glitch-soc's theming system.
- `app/views/admin/settings/registrations/show.html.haml`:
Upstream merged our captcha code, but there are some
conflicts due to glitch-soc's theming system.
Additional changes:
- `Gemfile`:
Upstream added hcaptcha dependency in another place in the file.
- `config/settings.yml`:
Upstream added the `captcha_enabled` setting in another place in the file.
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:
- `config/i18n-tasks.yml`:
Upstream added new ignored strings, glitch-soc has extra ignored strings
because of the theming system.
Added upstream's changes.
* Add peers endpoint toggle to Server Settings
This places the toggle under "Discovery" and expands the hint text to explain further what the endpoint is used for. Added a "Recommended" tag since it was recommended in v3 before it was removed.
Fixes https://github.com/mastodon/mastodon/issues/22222
* i18n normalize step
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/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/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.
Fixes#1649
This requires setting `HCAPTCHA_SECRET_KEY` and `HCAPTCHA_SITE_KEY`, then
enabling the admin setting at
`/admin/settings/edit#form_admin_settings_captcha_enabled`
Subsequently, a hCaptcha widget will be displayed on `/about` and
`/auth/sign_up` unless:
- the user is already signed-up already
- the user has used an invite link
- the user has already solved the captcha (and registration failed for another
reason)
The Content-Security-Policy headers are altered automatically to allow the
third-party hCaptcha scripts on `/about` and `/auth/sign_up` following the same
rules as above.
