Steps to reproduce the original issue:
1. Have two remote accounts, A that you don't follow, and B that you follow.
2. Have A post a toot and reply to it.
3. Boost A's reply from remote account B.
This used to cause the local instance to get A's reply but fail to link it to
the original post.
* Add regex filter on the community timeline and the public timeline
* correcting
* Adjust the height of header buttons
* Remove trailing spaces
* Remove trailing spaces
* Solve some code duplication
* reset the state of the locale files in app/javascript/mastodon/locales
* adjust to upstream
* adjust to upstream
* change keys of locale settings
* Sort results by the name
* Switch search method to simple `LIKE` matching instead of tsvector/tsquery
Previously we used scores from ts_rank_cd() to sort results, but it didn't work
because the function returns same score for all results. It's not for calculate
similarity of single words. Sometimes this bug even push out exact matching tag
from results.
Additionally, PostgreSQL supports prefix searching with standard btree index.
Using it offers simpler code, but also less index size and some speed.
* i18n: updated Polish translation
* i18n: updated Polish translation
btw it would be nice to have master-based Mastodon instance (even isolated from others) to test translation.
* Try fixing ThreadResolveWorker calls
From my understanding of ActiveRecord, a transaction is commited as soon as
the exit of the outmost ActiveRecord.transaction block. However, inner
transaction blocks will exit without the transaction being commited.
In this case, ThreadResolveWorker were fired *within* a transaction block,
so moving the call out of it should do the trick. However, this is somewhat
fragile, as this whole codepath could be called within yet another transaction.
* Set status thread within the transaction block if it is immediately available from database
* Add a StatusFilter class to identify visibility of statuses by accounts
* Extract StatusThreadingConcern from Status
* Clarify purpose of checking for nil account
* Redirect to streaming_api_base_url
When Rails receives a request to streaming API, it most likely
means that there is another host which is configured to respond
to it. This is to redirect clients to that host if
`STREAMING_API_BASE_URL` is set as another host.
* Use the new Ruby 1.9 hash syntax
Since Rails 5.1 missing migration version results in following error:
```
StandardError: Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:
```
This PR fixes all migration files.
* i18n Update : Add preference setting for delete toot modal
Adding a line for "Add preference setting for delete toot modal"
* i18n update for pin/unpin
Update to add two more translations
* i18n update to have the dates in plain occitan
* Removed the blank line
* %{selft} back in the translation
* Update annotate to version 2.7.2
* Update puma to version 3.9.0
* Update aws-sdk to version 2.9.28
* Update bootsnap to version 1.0.0
* Update nio4r to version 2.1.0
* Update nokogumbo to version 1.4.12
* Update oj to version 3.0.11
* Update pkg-config to version 1.2.3
* Update rubocop to version 0.49.1
* Update sidekiq-scheduler to version 2.1.5
* Update axios to version 0.16.2
* Update css-loader to version 0.28.4
* Update postcss-smart-import to version 0.7.4
* Update react-immutable-pure-component to version 0.0.5
* Update stringz to version 0.2.1
* Update style-loader to version 0.18.1
* Update websocket.js to version 0.1.9
* yarn upgrade
* Do not fall back to StreamEntry if object_type is unavailable in TagManager
Since 24c77e57b2, when Status, the only model
with stream_entry, and StreamEntry got its own logic in uri_for and
url_for, the purpose of the fallbacks to activity_type of StreamEntry
became unclear.
This commit removes the fallbacks. When adding another model with
stream_entry in future, consider to update uri_for and url_for.
* Cover TagManager more
