The Unicode sequence for this emoji starts with an
ASCII # character, which the browser's URI parser
truncates before sending the request to the
backend.
Akkoma and possibly others expect the `tag` field
in an EmojiReact activity to be an array, not just
a single object, so it's being wrapped into one
now. I'm not entirely sure whether this is the
idiomatic way of doing it tbh, but it works fine.
Using an emoji map was completely unnecessary in
the first place, because the reaction list from
the API response includes URLs for every custom
emoji anyway. The reaction list now also contains
a boolean field indicating whether it is an
external custom emoji, which is required because
people should only be able to react with Unicode
emojis and local custom ones, not with custom
emojis from other servers.
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.
The margins of the elements above and below the
main reaction list element overlapped before
reactions were added. Adding display: none to
empty reaction bars restores this exact look.
This also adds the comment in action_bar.js to
status_action_bar.js, clarifying that a future
version could improve this code by modifying
EmojiPickerDropdown.
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.
Reactions will be backported to the vanilla
flavour, which requires all related settings to
be accessible from the vanilla settings page
rather than the glitch specific settings modal.
This adds an extra item to the local settings for
specifying the number of reactions shown in toots.
The detailed status view always shows all
reactions.
Too many reactions on a single post quickly get
spammy, so they are now sorted by count and only
the first MAX_REACTIONS number of different
emojis are actually displayed.
the maximum number of reactions was previously
hardcoded to 8. this commit also fixes an
incorrect query in StatusReactionValidator where
it didn't count per-user reactions but the total
amount of different ones.
Conflicts:
- `app/javascript/packs/admin.jsx`:
Upstream reworked imports, but we had many changes.
Reworked imports as upstream did.
- `app/javascript/packs/public.jsx`:
Upstream reworked imports, but we had many changes.
Reworked imports as upstream did.
Conflicts:
- `tsconfig.json`:
Upstream changed the config to properly process imports.
Glitch-soc had previously already done so.
Changed the config to better match upstream.
Conflicts:
- `.github/dependabot.yml`:
Upstream made changes, but we had removed it.
Discarded upstream changes.
- `.rubocop_todo.yml`:
Upstream regenerated the file, we had some glitch-soc-specific ignores.
- `app/models/account_statuses_filter.rb`:
Minor upstream code style change where glitch-soc had slightly different code
due to handling of local-only posts.
Updated to match upstream's code style.
- `app/models/status.rb`:
Upstream moved ActiveRecord callback definitions, glitch-soc had an extra one.
Moved the definitions as upstream did.
- `app/services/backup_service.rb`:
Upstream rewrote a lot of the backup service, glitch-soc had changes because
of exporting local-only posts.
Took upstream changes and added back code to deal with local-only posts.
- `config/routes.rb`:
Upstream split the file into different files, while glitch-soc had a few
extra routes.
Extra routes added to `config/routes/settings.rb`, `config/routes/api.rb`
and `config/routes/admin.rb`
- `db/schema.rb`:
Upstream has new migrations, while glitch-soc had an extra migration.
Updated the expected serial number to match upstream's.
- `lib/mastodon/version.rb`:
Upstream added support to set version tags from environment variables, while
glitch-soc has an extra `+glitch` tag.
Changed the code to support upstream's feature but prepending a `+glitch`.
- `spec/lib/activitypub/activity/create_spec.rb`:
Minor code style change upstream, while glitch-soc has extra tests due to
`directMessage` handling.
Applied upstream's changes while keeping glitch-soc's extra tests.
- `spec/models/concerns/account_interactions_spec.rb`:
Minor code style change upstream, while glitch-soc has extra tests.
Applied upstream's changes while keeping glitch-soc's extra tests.
Conflicts:
- `app/javascript/styles/mastodon/forms.scss`:
Conflict because we ran eslint autofix on upstream files.
- `config/initializers/content_security_policy.rb`:
Code style changes but we have a different version.
Kept our version.
- `streaming/index.js`:
Upstream fixed a typo close to glitch-soc-only code.
Applied upstream's changes.
* Minor refactor and linting fixup in `flavours/glitch/actions/accounts.js`
This is some added boilerplate but it's much more consistent with the remaining
of the code, and avoids the linting issue.
* Fix missing /privacy-policy link in DM warning because of wrongly-named import
* Fix unnecessary import
* Fix regexp in flavours/glitch/utils/hashtag.js
The Unicode sequence for this emoji starts with an
ASCII # character, which the browser's URI parser
truncates before sending the request to the
backend.
Akkoma and possibly others expect the `tag` field
in an EmojiReact activity to be an array, not just
a single object, so it's being wrapped into one
now. I'm not entirely sure whether this is the
idiomatic way of doing it tbh, but it works fine.
Using an emoji map was completely unnecessary in
the first place, because the reaction list from
the API response includes URLs for every custom
emoji anyway. The reaction list now also contains
a boolean field indicating whether it is an
external custom emoji, which is required because
people should only be able to react with Unicode
emojis and local custom ones, not with custom
emojis from other servers.
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.
The margins of the elements above and below the
main reaction list element overlapped before
reactions were added. Adding display: none to
empty reaction bars restores this exact look.
This also adds the comment in action_bar.js to
status_action_bar.js, clarifying that a future
version could improve this code by modifying
EmojiPickerDropdown.
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.
Reactions will be backported to the vanilla
flavour, which requires all related settings to
be accessible from the vanilla settings page
rather than the glitch specific settings modal.
This adds an extra item to the local settings for
specifying the number of reactions shown in toots.
The detailed status view always shows all
reactions.
Too many reactions on a single post quickly get
spammy, so they are now sorted by count and only
the first MAX_REACTIONS number of different
emojis are actually displayed.
the maximum number of reactions was previously
hardcoded to 8. this commit also fixes an
incorrect query in StatusReactionValidator where
it didn't count per-user reactions but the total
amount of different ones.
When cancelling a reply, the language was still set to the language of the replied to toot.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
* Run eslint --fix
* Fix linting issues in video player and reduce divergences with upstream
This includes a behavior change of not auto-looping videos anymore. I don't
remember loops being ever intended, and they have been removed from upstream
a while ago, but we somehow missed the change.
* Fix lint issues in `app/javascript/flavours/glitch/selectors/index.js`
Those were basically caused by dead code that isn't present upstream, so
that brings us closer to upstream as well.
* Fix linting issue and bug in streaming/index.js
* Fix linting issues in config/webpack/shared.js
* Fix unused import in flavours/glitch/features/ui/index.js
* Fix linting issues and reduce divergences from upstream in flavours/glitch/features/ui/components/video_modal.jsx
* Fix linting issues in flavours/glitch/reducers
* Fix linting issues in glitch-soc onboarding modal
* Fix linting issues in flavours/glitch/features/ui/components/navigation_panel.jsx
* Remove dead code for unused local setting navbar_under
* Fix various linting issues
* Fix linting issues in flavours/glitch/components/scrollable_list.jsx and reduce divergences with upstream
* Disable font-family-no-missing-generic-family-keyword for font-awesome accessibility icons
* Run stylelint --fix
* Avoid `@extend` directives with doodle modal CSS
* Drop use of `@extend` for notification cleanup buttons SCSS
* Run prettier on SCSS
The Unicode sequence for this emoji starts with an
ASCII # character, which the browser's URI parser
truncates before sending the request to the
backend.
Akkoma and possibly others expect the `tag` field
in an EmojiReact activity to be an array, not just
a single object, so it's being wrapped into one
now. I'm not entirely sure whether this is the
idiomatic way of doing it tbh, but it works fine.
Using an emoji map was completely unnecessary in
the first place, because the reaction list from
the API response includes URLs for every custom
emoji anyway. The reaction list now also contains
a boolean field indicating whether it is an
external custom emoji, which is required because
people should only be able to react with Unicode
emojis and local custom ones, not with custom
emojis from other servers.
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.
The margins of the elements above and below the
main reaction list element overlapped before
reactions were added. Adding display: none to
empty reaction bars restores this exact look.
This also adds the comment in action_bar.js to
status_action_bar.js, clarifying that a future
version could improve this code by modifying
EmojiPickerDropdown.
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.
Reactions will be backported to the vanilla
flavour, which requires all related settings to
be accessible from the vanilla settings page
rather than the glitch specific settings modal.
This adds an extra item to the local settings for
specifying the number of reactions shown in toots.
The detailed status view always shows all
reactions.
Too many reactions on a single post quickly get
spammy, so they are now sorted by count and only
the first MAX_REACTIONS number of different
emojis are actually displayed.
the maximum number of reactions was previously
hardcoded to 8. this commit also fixes an
incorrect query in StatusReactionValidator where
it didn't count per-user reactions but the total
amount of different ones.
