Conflicts:
- `app/helpers/application_helper.rb`:
Conflict because of our different theming systems.
Updated accordingly, along with `app/helpers/theme_helper.rb`
and `app/helpers/theme_helper_spec.rb`.
Conflicts:
- `spec/requests/api/v2/instance_spec.rb`:
Conflict due to glitch-soc having a different default site name.
Updated the tests as upstream did, keeping glitch-soc's default name.
Conflicts:
- `app/lib/themes.rb`
- `app/views/layouts/application.html.haml`
- `app/views/layouts/embedded.html.haml`
- `app/views/layouts/error.html.haml`
- `config/settings.yml`
All these conflicts are because glitch-soc and upstream have different theming
systems and upstream changed a few things to have dynamic theme selection based
on system settings.
Conflicts were solved to take that into account, and `current_theme` has been
changed in the process to return a tuple of `[flavour, skin]` to be used in
the `theme_style_tags` helper.
Packs are now loaded from views, just like upstream, and are
identified by their filenames. The definition of `theme.yml` has
changed as such:
- `pack_directory` is now required
- `pack` is now unused
- `signed_in_preload` has been introduced
Conflicts:
- `config/routes/api.rb`:
glitch-soc has an extra `:destroy` action on notifications for historical reasons.
Kept it for now, while otherwise updating as upstream did.
Conflicts:
- `app/controllers/application_controller.rb`:
Not a real conflict, upstream fixed a bug in a line adjacent to code
modified by glitch-soc.
Ported upstream's change.
Conflicts:
- `Gemfile.lock`:
Changes were already cherry-picked and updated further in glitch-soc.
Kept glitch-soc's version.
- `README.md`:
Upstream updated its README, we have a completely different one.
Kept glitch-soc's README.
- `app/models/account.rb`:
Not a real conflict, upstream updated some lines textually adjacent
to glitch-soc-specific lines.
Ported upstream's changes.
* Ensure destruction of OAuth Applications notifies streaming
Due to doorkeeper using a dependent: delete_all relationship, the destroy of an OAuth Application bypassed the existing AccessTokenExtension callbacks for announcing destructing of access tokens.
* Ensure password resets revoke access to Streaming API
* Improve performance of deleting OAuth tokens
---------
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Ensure destruction of OAuth Applications notifies streaming
Due to doorkeeper using a dependent: delete_all relationship, the destroy of an OAuth Application bypassed the existing AccessTokenExtension callbacks for announcing destructing of access tokens.
* Ensure password resets revoke access to Streaming API
* Improve performance of deleting OAuth tokens
---------
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
