| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fix #8327
|
|
|
|
Fix #8275
As the batch operation progresses, the statuses_stats table grows,
and the WHERE NOT IN subquery becomes more expensive
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
* Move status counters to separate table, count replies
* Migration to remove old counter columns from statuses table
* Fix schema file
|
|
Adopted from GitLab CE. Generate new migration with:
rails g post_deployment_migration name_of_migration_here
By default they are run together with db:migrate. To not run them,
the env variable SKIP_POST_DEPLOYMENT_MIGRATIONS must be set
Code by Yorick Peterse <yorickpeterse@gmail.com>, see also:
https://gitlab.com/gitlab-org/gitlab-ce/commit/83c8241160ed48ab066e2c5bd58d0914a745197c
|
|
|
|
Include a dummy Account class in the migration script containing only the
attributes relevant to the migration in order to not rely as much on the
codebase being in sync with the database schema.
|
|
Adopted from GitLab CE. Generate new migration with:
rails g post_deployment_migration name_of_migration_here
By default they are run together with db:migrate. To not run them,
the env variable SKIP_POST_DEPLOYMENT_MIGRATIONS must be set
Code by Yorick Peterse <yorickpeterse@gmail.com>, see also:
https://gitlab.com/gitlab-org/gitlab-ce/commit/83c8241160ed48ab066e2c5bd58d0914a745197c
|
|
|
|
Include a dummy Account class in the migration script containing only the
attributes relevant to the migration in order to not rely as much on the
codebase being in sync with the database schema.
|
|
Conflicts:
app/controllers/accounts_controller.rb
app/javascript/mastodon/locales/pl.json
app/views/about/more.html.haml
Conflicts in `accounts_controller.rb` resolved by taking upstream's
version + our `use_pack`.
Conflicts in `pl.json` resolved by taking upstream's changes.
Conflicts in `aboute/more.html.haml` resolved by taking upstream's changes.
|
|
|
|
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
|
|
|
|
* Add federation relay support
* Add admin UI for managing relays
* Include actor on relay-related activities
* Fix i18n
|
|
Completely remove glitch-soc's Keyword Mutes, migrate
existing database records to CustomFilters.
Handling of client-side filters is still not implemented
in the glitch-soc front-end.
|
|
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.
|
|
(#7975)
* Add option to not consider word boundaries when filtering phrases
* Add a few tests for keyword/phrase filtering
|
|
* Add keyword filtering
GET|POST /api/v1/filters
GET|PUT|DELETE /api/v1/filters/:id
- Irreversible filters can drop toots from home or notifications
- Other filters can hide toots through the client app
- Filters use a phrase valid in particular contexts, expiration
* Make sure expired filters don't get applied client-side
* Add missing API methods
* Remove "regex filter" from column settings
* Add tests
* Add test for FeedManager
* Add CustomFilter test
* Add UI for managing filters
* Add streaming API event to allow syncing filters
* Fix tests
|
|
|
|
|
|
Conflicts:
app/models/user.rb
Resolved by adding :default_language to user settings fields
|
|
|
|
* Switch filtered_languages to chosen_languages
* Adjust interface
* Remove unused translations
|
|
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…
|
|
* Add autofollow option to invites
* Trigger CodeClimate rebuild
|
|
|
|
|
|
* Migration to cleanup blocked users that are still following
* use follow directly, commit schema
|
|
|
|
Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is
used to calculate scope. Next up: additions to the test suite to
demonstrate how scoping works.
|
|
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.
|
|
PG::UniqueViolation (#7688)
* Wrong exception class: ActiveRecord::RecordNotUnique, not PG::UniqueViolation
It's completely not obvious but PG::UniqueViolation is just a string inside the exception message, not the actual class of the exception
* Favourite does not have target_account_id
|
|
* Improve account index migration
- Display more progress in stdout
- Catch PG::UniqueViolation when re-attributing favourites
- Skip callbacks and validations when re-attributing other relationships
* Use in_batches to reduce table lock-up during account merge
* Use #say_with_time to benchmark each deduplication
|
|
|
|
Under rare circumstances the user record could have already been deleted before...
|
|
|
|
(#7658)
Fix #6937
Fix #6837
Fix #6667
|
|
|
|
|
|
Queries with the combination of account_id, id, and visibility can be
categorized in three types:
1. Querying for public and unlisted to enumerate statuses visible to
anyone.
2. Querying for public, unlisted, and private to enumerate statuses
visible to follower.
3. Querying for direct to enumerate own direct statuses.
1 and 2 is covered by the index with condition 'visibility IN (0, 1, 2)'.
It would bring better performance in case that there are many direct
statuses.
The index with condition 'visibility = 3' is just for 3. It would be much
faster to query direct statuses thanks to this query.
The total size of those two indexes are expected to be smaller than the
deleted one because they are partial and does not have to cover all the
table.
|
|
Conflicts:
app/controllers/invites_controller.rb
app/serializers/initial_state_serializer.rb
config/locales/ko.yml
|
