David Yip [Mon, 9 Oct 2017 22:28:28 +0000 (17:28 -0500)]
Add KeywordMute model.
Gist of the proposed keyword mute implementation:
Keyword mutes are represented server-side as one keyword per record.
For each account, there exists a keyword regex that is generated as one
big alternation of all keywords. This regex is cached (in Redis, I
guess) so we can quickly get it when filtering in FeedManager.
David Yip [Thu, 19 Oct 2017 15:59:50 +0000 (10:59 -0500)]
Make the compose area optionally scrollable.
On desktop, the compose text box grows to accommodate the content. On
mobile, the text box does not grow to accommodate text context, but does
grow to accommodate images. It is possible in both cases to overflow
the available area, which makes accessing other UI elements (e.g.
visibility setttings) difficult.
This commit makes the compose area optionally scrollable, which allows
those UI elements to remain available even if they go off-screen.
David Yip [Wed, 18 Oct 2017 16:52:34 +0000 (11:52 -0500)]
Update stylesheet imports in glitch components.
Commit 6e5471947438fc5883e72b8184663564ffadee28 moved the Mastodon
variables and mixins deeper in the directory hierarchy; this commit
brings the glitch components in line with that change.
Technowix [Wed, 18 Oct 2017 11:51:30 +0000 (13:51 +0200)]
Revert #5438 for FR (#5450)
As said here https://github.com/tootsuite/mastodon/pull/5438 the point of shortening the timestamp is legit, and after some time of adaptation no mistakes can be mades.
aschmitz [Tue, 17 Oct 2017 09:45:06 +0000 (04:45 -0500)]
Clean up reblog tracking keys, related improvements (#5428)
* Clean up reblog-tracking sets from FeedManager
Builds on #5419, with a few minor optimizations and cleanup of sets
after they are no longer needed.
* Update tests, fix multiply-reblogged case
Previously, we would have lost the fact that a given status was
reblogged if the displayed reblog of it was removed, now we don't.
Also added tests to make sure FeedManager#trim cleans up our reblog
tracking keys, fixed up FeedCleanupScheduler to use the right loop,
and fixed the test for it.
Eugen Rochko [Mon, 16 Oct 2017 18:44:31 +0000 (20:44 +0200)]
Keep references to all reblogs of a status on home feed (#5419)
* Keep references to all reblogs of a status on home feed
When inserting reblog: Add to set of reblogs of this status on
the feed, if original status was present in the feed, add it to
that set as well.
When removing a reblog: Remove it from that set. Take random
remaining item from the set. If one exists, re-insert it into feed,
otherwise do not re-insert anything.
Fix #4210
* When original is removed, toss out reblog references
Eugen Rochko [Mon, 16 Oct 2017 14:08:51 +0000 (16:08 +0200)]
Ensure that feed renegeration restores non-zero items (#5409)
Fix #5398
Ordering the home timeline query by account_id meant that the first
100 items belonged to a single account. There was also no reason to
reverse-iterate over the statuses. Assuming the user accesses the
feed halfway-through, it's better to have recent statuses already
available at the top. Therefore working from newer->older is ideal.
If the algorithm ends up filtering all items out during last-mile
filtering, repeat again a page further. The algorithm terminates
when either at least one item has been added, or if the database
query returns nothing (end of data reached)
unarist [Mon, 16 Oct 2017 13:58:23 +0000 (22:58 +0900)]
Fix un-reblogged status being at wrong position in the home timeline (#5418)
We've changed un-reblogging behavior when we implement Snowflake, to insert un-reblogged status at the position reblogging status existed.
However, our API expects home timeline is ordered by status ids, and max_id/since_id filters by zset score. Due to this, un-reblogged status appears as a last item of result set, and timeline expansion may skips many statuses.
So this reverts that change...reblogged status inserted at corresponding position to its id.
The main change of this PR is removing `order by visibility` hack.
This was introduced to force using of `index_statuses_on_account_id` instead of PK index, but it seems no longer needed probably due to `index_statuses_on_account_id_id`. Removing this avoids reading all rows, so really improves first fetching of the user who has lot of statuses.
I have also changed JOIN to IN + subquery, which slightly faster in most cases.
Eugen Rochko [Fri, 13 Oct 2017 14:44:29 +0000 (16:44 +0200)]
Fix UserTrackingConcern firing on every request, optimize some queries (#5368)
- For some reason, :if option on before_action did not work. It got
executed every time, returned false, and the action run anyway,
which led to the current_sign_in_at and sign_in_count being
updated on every request
- Return "do not filter" early in FeedManager#filter_from_home? if
the status is authored by receiver. Usually this method is not
called for own statuses at all, but it is called when Feed#get
uses the database
- Return early if #reload_stale_associations! has nothing to load
to save a database query with WHERE 1=0
Eugen Rochko [Fri, 13 Oct 2017 14:44:02 +0000 (16:44 +0200)]
When unfollowing, remove from home in web UI immediately (#5369)
Do NOT send "delete" through streaming API when unmerging from
home timeline. "delete" implies that the original status was
deleted, which is not true!
ThibG [Fri, 13 Oct 2017 10:58:13 +0000 (12:58 +0200)]
Fix remote status fetching for “pure” ActivityPub WEB_ACCOUNT users (#5372)
Remote ActivityPub users that have never been known as OStatus users
(whether or not they support it) will not have a “remote_url” attribute
set. In case they reside on an instance with WEB_DOMAIN ≠ LOCAL_DOMAIN,
the current check did rely on “remote_url” to verify the user's domain.
cat aescling's git repositories / mastodon.git / log