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.
Conflicts:
- `README.md`:
Discarded upstream changes: we have our own README
- `app/controllers/follower_accounts_controller.rb`:
Port upstream's minor refactoring
* Clear sessions on password change
* Rename User::clear_sessions to revoke_access for a clearer meaning
* Add reset paassword controller test
* Use User.find instead of User.find_for_authentication for reset password test
* Use redirect and render for better test meaning in reset password
Co-authored-by: Effy Elden <effy@effy.space>
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:
- `config/initializers/content_security_policy.rb`:
Our config file is pretty different from upstream.
Upstream changed CSP directive `script-src` to include
`wasm-unsafe-eval` instead of `unsafe-eval`, which we
did not include.
Added `wasm-unsafe-eval` to `script-src` to fix
execution of the OCR web worker.
- `package.json`:
Upstream updated a dependency (`array-includes`) textually
adjacent to a glitch-soc-only dependency (`atrament`).
Updated `array-includes` as upstream did.
Several controlers set quite intricate Cache-Control headers in order to
hopefully not be cached by any intermediate proxies or local caches. Unfortunately,
these headers are processed by ActionDispatch::HTTP::Cache in a way that squashes
and discards any values set alongside no-store other than private:
8015c2c2cf/actionpack/lib/action_dispatch/http/cache.rb (L207-L209)
We want to preserve no-store on these responses, but we might as well remove
parts that are going to be dropped anyway. As many of the endpoints in these
controllers are private to a particular user, we should also add "private",
which will be preserved alongside no-store.
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.
