Fix#271
Add back the `GET /api/v1/trends` API with the caveat that it does
not return tags that have not been allowed to trend by the staff.
When a hashtag begins to trend (internally) and that hashtag has
not been previously reviewed by the staff, the staff is notified.
The new admin UI for hashtags allows filtering hashtags by where
they are used (e.g. in the profile directory), whether they have
been reviewed or are pending reviewal, they show by how many people
the hashtag is used in the directory, how many people used it
today, how many statuses with it have been created today, and it
allows fixing the name of the hashtag to make it more readable.
The disallowed hashtags feature has been reworked. It is now
controlled from the admin UI for hashtags instead of from
the file `config/settings.yml`
Allow access to account settings, 2FA, authorized applications, and
account deletions to unconfirmed and pending users, as well as
users who had their accounts disabled. Suspended users cannot update
their e-mail or password or delete their account.
Display account status on account settings page, for example, when
an account is frozen, limited, unconfirmed or pending review.
After sign up, login users straight away and show a simple page that
tells them the status of their account with links to account settings
and logout, to reduce onboarding friction and allow users to correct
wrongly typed e-mail addresses.
Move the final sign-up step of SSO integrations to be the same
as above to reduce code duplication.
* Add support for an instance actor
* Skip username validation for local Application accounts
* Add migration script to create instance actor
* Make Codeclimate happy
* Switch to id -99 for instance actor
* Remove unused `icon` and `image` attributes from instance actor
* Use if/elsif/else instead of return + ternary operator
* Add instance actor to fresh installs
* Use instance actor as instance representative
Use instance actor for forwarding reports, relay operations, and spam
auto-reporting.
* Seed database in test environment
* Fix single-user mode
* Fix tests
* Fix specs to accomodate for an extra `Account`
* Auto-reject follows on instance actor
Following an instance actor might make sense, but we are not handling that
right now, so auto-reject.
* Fix webfinger lookup and serialization for instance actor
* Rename instance actor
* Make it clear in the HTML view that the instance actor should not be blocked
* Raise cache time for instance actor as there's no dynamic content
* Re-use /about/more with a flash message for instance actor profile
* Remove Salmon and PubSubHubbub endpoints
* Add error when trying to follow OStatus accounts
* Fix new accounts not being created in ResolveAccountService
* create account_identity_proofs table
* add endpoint for keybase to check local proofs
* add async task to update validity and liveness of proofs from keybase
* first pass keybase proof CRUD
* second pass keybase proof creation
* clean up proof list and add badges
* add avatar url to keybase api
* Always highlight the “Identity Proofs” navigation item when interacting with proofs.
* Update translations.
* Add profile URL.
* Reorder proofs.
* Add proofs to bio.
* Update settings/identity_proofs front-end.
* Use `link_to`.
* Only encode query params if they exist.
URLs without params had a trailing `?`.
* Only show live proofs.
* change valid to active in proof list and update liveness before displaying
* minor fixes
* add keybase config at well-known path
* extremely naive feature flagging off the identity proof UI
* fixes for rubocop
* make identity proofs page resilient to potential keybase issues
* normalize i18n
* tweaks for brakeman
* remove two unused translations
* cleanup and add more localizations
* make keybase_contacts an admin setting
* fix ExternalProofService my_domain
* use Addressable::URI in identity proofs
* use active model serializer for keybase proof config
* more cleanup of keybase proof config
* rename proof is_valid and is_live to proof_valid and proof_live
* cleanup
* assorted tweaks for more robust communication with keybase
* Clean up
* Small fixes
* Display verified identity identically to verified links
* Clean up unused CSS
* Add caching for Keybase avatar URLs
* Remove keybase_contacts setting
* Add polls
Fix#1629
* Add tests
* Fixes
* Change API for creating polls
* Use name instead of content for votes
* Remove poll validation for remote polls
* Add polls to public pages
* When updating the poll, update options just in case they were changed
* Fix public pages showing both poll and other media
* Add hashtag filter to profiles
GET /@:username/tagged/:hashtag
GET /api/v1/accounts/:id/statuses?tagged=:hashtag
* Display featured hashtags on public profile
* Use separate model for featured tags
* Update featured hashtag counters on-write
* Limit featured tags to 10
* Allow to show a specific status in the admin interface
* Let the front-end know the current account is a moderator
* Add admin links to status and account menus
If the current logged-in user is an admin, add quick links to the admin
interface in account and toot dropdown menu. Suggestion by @ashkitten
* Use @statuses.first instead of @statuses[0]
* Add local followers page to admin account UI
For moderation, I often find myself wondering who, locally, is following
a remote user. Currently, to see this, I have to go back to the web UI,
paste in their full handle, click their profile, and go to the
"Followers" tab (plus, this information is incidental, and if mastodon
ever decides to resolve all of the follower information, there will be
no place local followers are shown). This PR adds a new page which is
accessible via the "following" count on the admin's account view
page, which shows the local followers. (It has filter parameters for
account location to indicate that only local followers are shown, and
leave room for expansion if mastodon ever decides to store the entire
remote follow list).
* Normalize en.yml
* Add REST API for creating an account
The method is available to apps with a token obtained via the client
credentials grant. It creates a user and account records, as well as
an access token for the app that initiated the request. The user is
unconfirmed, and an e-mail is sent as usual.
The method returns the access token, which the app should save for
later. The REST API is not available to users with unconfirmed
accounts, so the app must be smart to wait for the user to click a
link in their e-mail inbox.
The method is rate-limited by IP to 5 requests per 30 minutes.
* Redirect users back to app from confirmation if they were created with an app
* Add tests
* Return 403 on the method if registrations are not open
* Require agreement param to be true in the API when creating an account
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
* Add conversations API
* Add web UI for conversations
* Add test for conversations API
* Add tests for ConversationAccount
* Improve web UI
* Rename ConversationAccount to AccountConversation
* Remove conversations on block and mute
* Change last_status_id to be a denormalization of status_ids
* Add optimistic locking
* Allow min_id pagination in Feed#get
* Add min_id pagination to home and list timeline APIs
* Add min_id pagination to account statuses, public and tag APIs
* Remove unused stub in reports API
* Use min_id pagination in notifications, favourites, and fix order
* Fix HomeFeed#from_database not using paginate_by_id
* Add remote interaction dialog for toots
* Change AuthorizeFollow into AuthorizeInteraction, support statuses
* Update brakeman.ignore
* Adjust how interaction buttons are display on public pages
* Fix tests
DELETE /api/v1/suggestions/:account_id
When blocking, remove suggestion from both sides. Muting not affected,
since muting is supposed to be invisible to the target.
