* Add code for creating/managing apps to settings section
* Add specs for app changes
* Fix controller spec
* Fix view file I pasted over by mistake
* Add locale strings. Add 'my apps' to nav
* Add Client ID/Secret to App page. Add some visual separation
* Fix rubocop warnings
* Fix embarrassing typo
I lost an `end` statement while fixing a merge conflict.
* Add code for creating/managing apps to settings section
- Add specs for app changes
- Add locale strings. Add 'my apps' to nav
- Add Client ID/Secret to App page. Add some visual separation
- Fix some bugs/warnings
* Update to match code standards
* Trigger notification
* Add warning about not sharing API secrets
* Tweak spec a bit
* Cleanup fixture creation by using let!
* Remove unused key
* Add foreign key for application<->user
* Add overview of active sessions
* Better display of browser/platform name
* Improve how browser information is stored and displayed for sessions overview
* Fix test
* Fix#2347 - Bind web UI access token to session
When you logout, session also destroys the access token, so it's no longer
valid. If access token is destroyed some other way, the session is also
destroyed, requiring a re-login.
Fix#1681 - Add scheduler to remove revoked access tokens and grants
* Fix test
* Add overview of active sessions
* Better display of browser/platform name
* Improve how browser information is stored and displayed for sessions overview
* Fix test
* 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.
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
* Adding account domain blocks that filter notifications and public timelines
* Add tests for domain blocks in notifications, public timelines
Filter reblogs of blocked domains from home
* Add API for listing and creating account domain blocks
* API for creating/deleting domain blocks, tests for Status#ancestors
and Status#descendants, filter domain blocks from them
* Filter domains in streaming API
* Update account_domain_block_spec.rb
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Fix conversation migration
* More spec coverage for status before_create
* Prevent n+1 query when generating Atom with the new conversations
* Improve code style
* Remove redundant local variable
* Naive approached to timeline filtering
* Convert allowed_languages into a db column
* Allow users to choose languages to see statuses in
* Style list items as two columns
* Add a hint to explain language filtering preference
* OEmbed support for PreviewCard
* Improve ProviderDiscovery code failure treatment
* Do not crawl links if there is a content warning, since those
don't display a link card anyway
* Reset db schema
* Fresh migrate
* Fix rubocop style issues
Fix#1681 - return existing access token when applicable instead of creating new
* Fix test
* Extract http client to helper
* Improve oembed controller
* Fixes#1985
- add migration AddMediaAttachmentMeta, which add meta field to media_attachments
- before saving attachment, set file meta if needed
- add meta in api
* add spec
* align the “size” format for image and video
* fix code climate
* fixes media_attachment_spec.rb
* Add a ReportFilter class
* Add reports and targeted_reports relationships to Account
* Use ReportFilter from admin/reports controller
* Link to admin/reports filtered views from admin account show view
* Add indexes to reports.account_id and reports.target_account_id
* 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
* 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
* 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
before. In the API, attachments now can be either image, video or gifv. Gifv
is to be treated like images in terms of behaviour, but are videos by file
type.
Eugen Rochko