We don't have releases, so it don't make sense to mention.
On the other hand, a lot of our code is from upstream, so encourage people to
check whether it is a bug in glitch-soc or upstream.
Conflicts:
.circleci/config.yml
app/controllers/authorize_follows_controller.rb
app/javascript/packs/public.js
Moved new stuff from packs/public.js to core/public.js.
Added appropriate use_pack in new controllers.
This includes clicks on hashtags, mentions, display names and media in the
timeline; and usernames in reply-indicator, detailed status, and the boost
modal.
* Add “bundle clean” suggestion from CircleCI doc
Cf. https://circleci.com/docs/2.0/caching/#bundler-ruby
* Use workspaces instead of caches for ruby gems
Cache are not guaranteed to be available, while the test jobs *require* their
depencies to run. Workspaces are thus more suitable.
One downside is that the order of workspace layer additions need to be
deterministic, which is why install-ruby{2.3,2.4} now depend on
install-ruby2.5.
* Add remote interaction dialog for toots
* Change AuthorizeFollow into AuthorizeInteraction, support statuses
* Update brakeman.ignore
* Adjust how interaction buttons are display on public pages
* Fix tests
Conflicts:
app/models/status.rb
db/migrate/20180528141303_fix_accounts_unique_index.rb
db/schema.rb
Resolved by taking upstream changes (no real conflicts, just glitch-soc
specific code too close to actual changes).
There were some concerns with the custom filter migration script dropping a table,
thus making it unsafe to run in a zero-downtime setting. Upstream introduced
a way to run migrations after deployment, so revisit the old migration script to
make use of this.
* Disable the animated rainbow text when the “Reduce motion” setting is set
* Get rid of the Content Warning rainbows
* Revert to default color for CWs in admin view
Since that colorscheme is apparently broken for some colorblind people.
* Use HTML5's details and summary for statuses with CWs in admin interface
* Allow accessing local private/DM messages by URL
(Provided the user pasting the URL is authorized to see the toot, obviously)
* Fix SearchServiceSpec tests
- Preload video metadata if the video is loaded in detailed view, as it is
likely to get played, and metadata is useful for seeking in the video.
- Preload video data if it's fullscreen as it is extremely likely to get
played right after being put in fullscreen (although those are two steps).
- Preload video data if the user has clicked the position slider, as the video
will play as soon as the mouse button is released, and video metadata is
needed to properly seek into the video.