Follow-up to #2599. When a domain block with `reject_media` is
added or `rake mastodon:media:remove_remote` is invoked, mastodon
deletes the locally cached attachments and avatars but does not
reflect that change in the database, causing the `file` fields to
still have values. This change persists the deletion in the
database and sets the attachment type to unknown.
This also introduces a one-off rake task that sets all attachments
without a local file to the "unknown" type. The upgrade notes for
the next release should contain a post-upgrade step with
`rake mastodon:media:set_unknown`.
In #2110, a new attachment type "unknown" was introduced for
attachments that were rejected due to a domain being blocked using
reject_media. However, the "type" field was never set to "unknown"
because a default value of "0" (image) is set for that column,
causing the `type.blank?` expression to always equal false.
This version uses type_changed? instead, causing the type to be set
to "unknown" unless a type has been explicitly set. This introduces
a small change in behaviour causing the type to be set to unknown
before paperclip calls `before_post_process`. Presumably this
behaviour is more appropriate than the current one because the
attachment type has not been determined by that point.
Included are new tests for `ProcessFeedService` and
`UpdateRemoteProfileService` which now check that remote media is
downloaded for non-blocked domains and is rejected for others.
In #2505, the authorize_follow views were renamed to
authorize_follows. This change was not applied in the show view
of admin/reports, which causes a 500 when reports are viewed.
This introduces a new per-user preference called
"Auto-play animated GIFs", which is enabled by default. When a
user disables this setting, gifs in toots become click-to-play.
Previews of animated gifs were changed to display the video play
button so that users can distinguish them from regular images.
This setting also affects account avatars in the detailed account
view, which was changed to use the same hover-to-play mechanism
that is used for animated avatars in timelines.
Fixes#1652
* Add recovery code support for two-factor auth
When users enable two-factor auth, the app now generates ten
single-use recovery codes. Users are encouraged to print the codes
and store them in a safe place.
The two-factor prompt during login now accepts both OTP codes and
recovery codes.
The two-factor settings UI allows users to regenerated lost
recovery codes. Users who have set up two-factor auth prior to
this feature being added can use it to generate recovery codes
for the first time.
Fixes#563 and fixes#987
* Set OTP_SECRET in test enviroment
* add missing .html to view file names
Patrick FigelandEugen Rochko