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).
* Allow accessing local private/DM messages by URL
(Provided the user pasting the URL is authorized to see the toot, obviously)
* Fix SearchServiceSpec tests
Manually-resolved conflicts:
.circleci/config.yml
app/controllers/accounts_controller.rb
app/controllers/auth/passwords_controller.rb
app/controllers/statuses_controller.rb
app/javascript/packs/public.js
app/models/media_attachment.rb
app/views/stream_entries/_content_spoiler.html.haml
app/views/stream_entries/_media.html.haml
config/locales/en.yml
config/locales/ja.yml
config/locales/pl.yml
lib/mastodon/version.rb
Some content from app/javascript/packs/public.js has been split to
app/javascript/core/settings.js.
Translation strings for glitch-soc's keyword mutes were dropped.
Everything else was mostly “take both”.
Conflicts:
Dockerfile
app/javascript/packs/common.js
config/webpack/loaders/sass.js
config/webpack/shared.js
db/schema.rb
package.json
yarn.lock
A lot of the conflicts come from updating webpack.
Even though upstream deleted app/javascript/packs/common.js, I kept
glitch-soc's version as it unifies JS/CSS packs behavior across flavours.
Ported glitch changes to webpack 4.x
Conflicts:
README.md
app/controllers/statuses_controller.rb
app/lib/feed_manager.rb
config/navigation.rb
spec/lib/feed_manager_spec.rb
Conflicts were resolved by taking both versions for each change.
This means the two filter systems (glitch-soc's keyword mutes and tootsuite's
custom filters) are in place, which will be changed in a follow-up commit.
* Re-add follow recommendations API
GET /api/v1/suggestions
Removed in 8efa081f21 due to Neo4J
dependency. The algorithm uses triadic closures, takes into account
suspensions, blocks, mutes, domain blocks, excludes locked and moved
accounts, and prefers more recently updated accounts.
* Track interactions with people you don't follow
Replying to, favouriting and reblogging someone you're not following
will make them show up in follow recommendations. The interactions
have different weights:
- Replying is 1
- Favouriting is 10 (decidedly positive interaction, but private)
- Reblogging is 20
Following them, muting or blocking will remove them from the list,
obviously.
* Remove triadic closures, ensure potential friendships are trimmed
Conflicts:
app/javascript/mastodon/initial_state.js
db/schema.rb
Upstream added a new field to initial_state.
Not too sure about what happened with db/schema.rb though…
Ref: cfa9b6e13a
This breaks compatibility with pre-2.3.0 Mastodon and older
software, but at the time of writing the network is >80% above
that version.
Compatibility broken only for toots with no text.
* Send rejections to followers when user hides domain they're on
* Use account domain blocks for "authorized followers" action
Replace soft-blocking (block & unblock) behaviour with follow rejection
* Split sync and async work of account domain blocking
Do not create domain block when removing followers by domain, that
is probably unexpected from the user's perspective.
* Adjust confirmation message for domain block
* yarn manage:translations
Old statuses and statuses from Pawoo, which runs a modified version of
Mastodon, may not have been marked sensitive even if spoiler text is
present.
Such statuses are still not marked sensitve if they are local or
arrived before version upgrade. Marking recently fetched remote status
sensitive contradicts the behavior.
Considering what people expected when they authored such statuses, this
change removes the sensitivity enforcement.
Conflicts:
app/javascript/mastodon/locales/en.json
app/javascript/mastodon/locales/ja.json
app/javascript/mastodon/locales/pl.json
The above conflicts appear to be a text conflict introduced by
glitch-soc's additional level of columns (i.e. moving a bunch of columns
under the Misc option). They were resolved via accept-ours.
Do not touch statuses_count on accounts table when mass-destroying
statuses to reduce load when removing accounts, same for
reblogs_count and favourites_count
Do not count statuses with direct visibility in statuses_count
Fix#828
* Track trending tags
- Half-life of 1 day
- Historical usage in daily buckets (last 7 days stored)
- GET /api/v1/trends
Fix#271
* Add trends to web UI
* Don't render compose form on search route, adjust search results header
* Disqualify tag from trends if it's in disallowed hashtags setting
* Count distinct accounts using tag, ignore silenced accounts
Conflicts:
app/javascript/styles/mastodon-light.scss
config/locales/en.yml
config/locales/fr.yml
config/locales/simple_form.pl.yml
config/themes.yml
Conflicts resolved by deleting config/themes.yml,
marking app/javascript/styles/mastodon-light.scss as added,
and taking all new translation strings, not removing anything from
them.
Updates account `uri` field on each call to `update_account` instead of
only once during `create_account` to mirror the same behavior in OStatus
`ResolveAccountService` class [0].
ActivityPub accounts are identified using `@username` and `@domain` pair
instead of URI since #6842.
This fixes#7479: a bug when the account identified by `@username` and
`@domain` changes its URI.
[0]:
03b69ebc45/app/services/resolve_account_service.rb (L121)
When an ActivityPub Announce is processed and the boosted toot is not known,
fetch it on behalf of one of the booster's followers. This is to allow
fetching self-boosts of previously-unknown private toots.
If fetching on behalf of a user fails, try fetching it anonymously: the
selected follower of a boosting user may be banned by the boosted toot's
author.
