Conflicts:
- `config/initializers/content_security_policy.rb`:
Upstream changed how asset host CSP directives are used, and glitch-soc has
a pretty different CSP file.
It may be worth reconsidering the differences between upstream and glitch-soc
but for now, just port the change.
Conflicts:
- `README.md`:
Upstream has updated its README, we have a completely different one.
Kept ours.
- `app/views/auth/sessions/two_factor.html.haml`:
Upstream refactored stuff and the conflict is because of glitch-soc's theming
system.
Ported upstream changes while accounting for the different theming system.
Conflicts:
- `app/controllers/concerns/web_app_controller_concern.rb`:
Upstream changed the order of Action Controller filters for web app
controllers.
Glitch-soc has an extra filter due to its theming system.
Changed the order accordingly.
- `app/views/settings/preferences/appearance/show.html.haml`:
Conflict due to an extra newline in glitch-soc.
Removed that newline and applied upstream's changes.
Conflicts:
- `app/controllers/auth/registrations_controller.rb`:
Not a real conflict. Upstream removed the `set_instance_presenter` private
method from this class, and glitch-soc has an extra private method right
besides it for the theming system.
Removed `set_instance_presenter` as upstream did.
- `app/controllers/auth/sessions_controller.rb`:
Not a real conflict. Upstream removed the `set_instance_presenter` private
method from this class, and glitch-soc has an extra private method right
besides it for the theming system.
Removed `set_instance_presenter` as upstream did.
Conflicts:
- `config/initializers/content_security_policy.rb`:
Upstream added some code to add the Identity Provider's sign-in endpoint to
the `form-action` Content Security Policy directive but our version of the
file is pretty different.
Ported the change.
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-releases.yml`:
Upstream changed comments close to a line we modified to account for
different container image repositories.
Updated the comments as upstream did.
Conflicts:
- `README.md`:
Upstream has updated their README, we have a completely different one.
Kept ours.
- `config/initializers/content_security_policy.rb`:
Upstream has updated their development CSPs, while we disable CSPs in
the development environment.
Kept our version.
Conflicts:
- `app/javascript/packs/public.jsx`:
Upstream updated code that we actually moved to `app/javascript/core/settings.js`.
Applied the changes there.
Conflicts:
- `app/views/settings/preferences/other/show.html.haml`:
Upstream moved some settings, where glitch-soc has an extra setting.
Ported upstream changes, moving the same settings as them.
Conflicts:
- `.rubocop_todo.yml`:
Upstream regenerated this file, glitch-soc had a specific ignore.
- `README.md`:
Upstream updated its README, but glitch-soc has a completely different one.
Kept glitch-soc's README
Conflicts:
- `app/controllers/authorize_interactions_controller.rb`:
Small conflict due to our theming system.
- `streaming/index.js`:
Upstream refactored part of the streaming server.
We had some extra logic for handling local-only posts.
Applied the refactor.
Conflicts:
- `db/schema.rb`:
Upstream regenerated the schema file using Rails 7, the conflicts are
caused by our extra columns.
Applied upstream's changes, but keeping our extra columns.
Conflicts:
- `app/models/account.rb`:
Upstream added new validations close to lines on which glitch-soc had
modified validations to handle custom limits set through environment
variables.
Ported upstream changes.
- `config/initializers/content_security_policy.rb`:
Upstream added `AZURE_ALIAS_HOST`. Glitch-soc's version of the file is
completely different.
Added `AZURE_ALIAS_HOST` to our version of the file.
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/application_controller.rb:
Upstream added an `include` where we had an extra `include` due to
glitch-soc's theming system.
Added upstream's new `include`.
Conflicts:
- `db/migrate/20180831171112_create_bookmarks.rb`:
Upstream ran a lint fix on this file, but this file is different in
glitch-soc because the feature was added much earlier.
Ran the lint fix on our own version of the file.
Conflicts:
- `app/serializers/initial_state_serializer.rb`:
Upstream renamed an initial state parameter, where we had extra ones.
Renamed as upstream did.
- `app/workers/feed_insert_worker.rb`:
Upstream wrapped database query in a block, we had extra database
queries because of the DM timeline.
Moved everything in the block.
Status reactions had an API similar to that of
announcement reactions, using PUT and DELETE at a
single endpoint. I believe that for statuses, it
makes more sense to follow the convention of the
other interactions and use separate POST endpoints
for create and destroy respectively.
Turns out the strange error where it would delete
the wrong reaction occurred because I forgot to
pass the emoji name to the query, which resulted
in the database deleting the first reaction it
found. Also, this removes the unused set_reaction
callback and includes the Authorization module for
the status reactions controller.
