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/views/layouts/application.html.haml`:
Upstream removed the `crossorigin` attribute from `preload_pack_asset`.
Glitch-soc had different calls to `preload_pack_asset` because of the
different theming system.
Ported the change.
- `app/views/layouts/embedded.html.haml`:
Upstream removed the `crossorigin` attribute from `preload_pack_asset`.
Glitch-soc had different calls to `preload_pack_asset` because of the
different theming system.
Ported the change.
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/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.
Conflicts:
- `app/models/user_settings.rb`:
Upstream added a constraint on a setting textually close
to glitch-soc-only settings.
Applied upstream's change.
- `lib/sanitize_ext/sanitize_config.rb`:
Upstream added support for the `translate` attribute on a few elements,
where glitch-soc had a different set of allowed elements and attributes.
Extended glitch-soc's allowed attributes with `translate` as upstream did.
- `spec/validators/status_length_validator_spec.rb`:
Upstream refactored to use RSpec's `instance_double` instead of `double`,
but glitch-soc had changes to tests due to configurable max toot chars.
Applied upstream's changes while keeping tests against configurable max
toot chars.
Conflicts:
- `package.json`:
Upstream changed various script definitions in lines surrounding the one for
`i18n:extract`, which had glitch-soc-specific changes.
Updated the scripts as upstream did, while keeping our changes to
`i18n:extract`.
Instead of processing tag and then look for the custom emoji, let the processing return an emoji.
Add `name` to `process_emoji_tags` to check if it matches the shortcode.
Removed `process_single_emoji` and added its code to `process_emoji_tags`
Removed arg from `maybe_process_misskey_reaction`.
Ideally, `original_status` should be a global object, but I wanted to modify vanilla code as little as possible.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Right now Misskey users were able to react, but couldn't remove their reactions.
delegates `Undo` for a `Like` to `undo_emoji_react` when there is no favourite found.
(Misskey `Like` activities can still create a fav when the emoji tag is invalid, I don't see the point though)
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Processing all custom emojis is neither wise nor necessary as both `Like` and `EmojiReact` only expect a single custom emoji
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
These occur when an account tries to react with disabled custom emojis.
In both `EmojiReact` and `Like? activities, the activity is discarded.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Emoji reactions containing custom emojis from
remote instances were assumed to already have
been downloaded and stored in the database.
This might obviously not be the case.
