| Age | Commit message (Collapse) | Author |
|---|
|
* reduce unneed query when post without attachements.
This commit reduce following query:
```
MediaAttachment Load (0.9ms) SELECT "media_attachments".* FROM "media_attachments" WHERE "media_attachments"."status
_id" IS NULL AND 1=0 ORDER BY id asc
```
* fixed for more simple changes.
|
|
|
|
* Add language detection via WhatLanguage and (de)serialization of it through Atom
* Fix default language in ProcessFeedService
* Re-add newline before 'react-rails' Gem to fix groupings
Fixes Code Climate issue
|
|
|
|
The <link rel="mentioned" /> tag refers to accounts by href. So we were
matching the DB by the url attribute, and falling back to HTTP look-up.
However, GS and Mastodon use profile URLs as URIs, too, and the match
for that was missing. This could potentially alleviate some extra network
requests
|
|
|
|
|
|
Create MediaAttachment but without actual file download when domain is blocked with reject_media set to true
Clean up old media files when creating a new domain block with reject_media set to true
Return remote_url in media attachments API if local file is not present
Undo domain block action in admin UI
Ability to enable reject_media from admin UI
|
|
|
|
* Begin coverage for account search service
* Coverage for hashtag query
* Coverage for calling local vs remote find based on domain presence
* Spec to check that exact matches are not duped
* Coverage of resolve option
* Coverage for account being provided
* Start to refactor account search service
* Isolate query username and domain methods
* Isolate exact_match method
* Extract methods for local and remote results
* Simplify local vs remote and account isoliation
* Extract methods for local and remote results
* Simplify de-dupe of exact match
* Simplify logic to check for non exact remotes
* Cache some methods
* Remove nil from exact_match from results array
* Return exact matches first
* Use find_remote even with no domain
Account.find_local is just an alias for Account.find_remote(user, nil) - so we
can not bother with the conditional here, and call find_remote directly.
|
|
* Refresh local info for remote accounts when webfinger returns new values
It only refreshes account info if one of the URLs or the public-key changes,
in which cases it refreshes the full info, re-downloading the feeds from that
user.
Some special handling should probably be done when the public key changes,
but I have been unable to find any use for it in Mastodon yet.
* Re-fetch remote users we aren't subscribed to.
This might induce performance issues, we might want to only do that for users
we explicitly attempted to subscribe but failed to.
* Refactor changes
* Do not refresh existing remote account details more than once a day
* Avoid re-fetching webfinger info in tests unless otherwise specified
|
|
users (#1267)
* Allow running mastodon on a different domain as the one used for identifying users
* Alter documentation of WEB_DOMAIN to make clear it shouldn't be used unless the admin knows what they are doing
* Compare to web_domain instead of local_domain when dealing with feeds/API
* Correctly identify mentions to local accounts
Mentions URLs point to the person's web profile, i.e., the user page served on WEB_DOMAIN.
|
|
|
|
This was used in the views/atom/user_stream.xml.ruby file, which no longer is
used.
|
|
(#1344)
The goal of this change is to enhance Mastodon's handling of remote domains
for which the APIs reside on a different host (see issue #1032).
Indeed, when a remote user unknown to Mastodon is mentionned, only its profile
URL (e.g. https://social.example.org/users/User) is known, and Mastodon has to
build a @username@domain handle for it. To do so, Mastodon fetches the user's
atom feed (e.g., https://social.example.org/users/User.atom) and uses its
content to get the username part of the handle, and the URL's host part to
build the domain (e.g., @User@social.example.org). This handle is then used
for a Webfinger request.
In the case where example.org serves the Webfinger info for @User@example.org
and all feeds and APIs are hosted at social.example.org, Mastodon will still
build @User@social.example.org and fail at resolving the account's details
through Webfinger.
This patch changes this behaviour by using the author's email address from
the atom feed to build the handle. In Mastodon-generated atom feeds, the
email address is always the handle it expects for federation.
|
|
* Fix #1141, fix #1126 - Work through UpdateRemoteProfileService for both <feed> and <entry> top-level tags
* Improve code quality, remove line unrelated to fix
|
|
Fix #1141 on remote follow
|
|
The async action is send before persist, account.id not yet generated
Pull queue receive 'nil' so no profile update.
|
|
|
|
These are currently user facing errors, but are not localized. This adds the
ability for these messages to be localized.
|
|
(#1124)
* Rewrite Atom generation from stream entries to use Ox instead of Nokogiri::Builder
StreamEntry is now limited to only statuses, which allows some optimization. Removed
extra queries on AccountsController#show. AtomSerializer instead of AtomBuilderHelper
used in AccountsController#show, StreamEntriesController#show, StreamEntryRenderer
and PubSubHubbub::DistributionWorker
PubSubHubbub::DistributionWorker moves n+1 DomainBlock query to PubSubHubbub::DeliveryWorker
instead.
All Salmon slaps that aren't based on StreamEntry still use AtomBuilderHelper and Nokogiri
* All Salmon slaps now use Ox instead of Nokogiri. No touch from status on account
|
|
|
|
RemoveStatusService,
slightly optimized FanOutOnWriteService again
|
|
|
|
|
|
|
|
|
|
make regeneration worker unique, (only schedule/execute once at a time)
|
|
race conditions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
index,
add ability to open status by URL from search (fix #53)
|
|
Returns accounts, statuses, hashtags arrays
|
|
|
|
results
|
|
adjusted to allow choosing it, yet
|
|
about them would be processed only after the entire status is processed
|
|
|
|
|
|
Add ability to search accounts by display name
|
|
|
|
rmhasan-fix_462
|
|
make status pagination headers generation more lax about next page
existing
|
|
|
|
upon un-reblogging. Check if the reblog was in the feed in the first
place. It might have been filtered on distribution.
|
|
of mix of video and images in status, just wasn't rendering
the show action. I moved the validation before the status creation
|
