* 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
* Make custom emoji domains case sensitive #9351
* Fixup style in downcase_domain to comply with codeclimate.
* switch if! to unless
* Don't use transactions, operate in batches.
Also revert spurious schema change.
* fix: change Identity's id column to a bigint
This appears to be the last model created using a 5.0 migration,
where column types defaulted to `integer` rather than `bigint`.
This migration changes the column type to match that of all of the
other ID columns.
* Change user_id column in identities to bigint and fix down-migration
* Add locality check to ActivityPub::FetchRemoteAccountService
Fix#8643
Because there are a few places where it is called, it is difficult
to confirm if they all previously checked it for locality. It's better
to make sure within the service.
* Remove faux-remote duplicates of local accounts
Conflicts:
- app/controllers/admin/base_controller.rb
- app/controllers/filters_controller.rb
- app/controllers/invites_controller.rb
- app/controllers/settings/deletes_controller.rb
- app/controllers/settings/exports_controller.rb
- app/controllers/settings/follower_domains_controller.rb
- app/controllers/settings/migrations_controller.rb
- app/controllers/settings/notifications_controller.rb
- app/controllers/settings/preferences_controller.rb
- app/controllers/settings/two_factor_authentication/recovery_codes_controller.rb
- app/javascript/packs/public.js
- app/views/settings/profiles/show.html.haml
Conflicts were mostly due to the addition of body classes to the settings page,
this was caused by rejecting upstream changes for most of those files and
modifying Settings::BaseController instead.
Another cause of conflicts was the deletion of client-side checking of
display name / bio length, this was modified in app/javascript/core/settings.js
instead.
Conflicts:
- .github/ISSUE_TEMPLATE/bug_report.md
Took our version.
- CONTRIBUTING.md
Updated the embedded copy of upstream's version.
- README.md
Took our version.
- app/policies/status_policy.rb
Not a real conflict, took code from both.
- app/views/layouts/embedded.html.haml
Added upstream's changes (dns-prefetch) and fixed
`%body.embed`
- app/views/settings/preferences/show.html.haml
Reverted some of upstream changes, as we have a
page dedicated for flavours and skins.
- config/initializers/content_security_policy.rb
Kept our version of the CSP.
- config/initializers/doorkeeper.rb
Not a real conflict, took code from both.
* Add silent column to mentions
* Save silent mentions in ActivityPub Create handler and optimize it
Move networking calls out of the database transaction
* Add "limited" visibility level masked as "private" in the API
Unlike DMs, limited statuses are pushed into home feeds. The access
control rules between direct and limited statuses is almost the same,
except for counter and conversation logic
* Ensure silent column is non-null, add spec
* Ensure filters don't check silent mentions for blocks/mutes
As those are "this person is also allowed to see" rather than "this
person is involved", therefore does not warrant filtering
* Clean up code
* Use Status#active_mentions to limit returned mentions
* Fix code style issues
* Use Status#active_mentions in Notification
And remove stream_entry eager-loading from Notification
* 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
Conflicts:
db/migrate/20170716191202_add_hide_notifications_to_mute.rb
spec/controllers/application_controller_spec.rb
Took our version, upstream changes were only minor style linting.
Conflicts:
.circleci/config.yml
app/controllers/authorize_follows_controller.rb
app/javascript/packs/public.js
Moved new stuff from packs/public.js to core/public.js.
Added appropriate use_pack in new controllers.
Conflicts:
app/models/status.rb
db/migrate/20180528141303_fix_accounts_unique_index.rb
db/schema.rb
Resolved by taking upstream changes (no real conflicts, just glitch-soc
specific code too close to actual changes).
There were some concerns with the custom filter migration script dropping a table,
thus making it unsafe to run in a zero-downtime setting. Upstream introduced
a way to run migrations after deployment, so revisit the old migration script to
make use of this.
Include a dummy Account class in the migration script containing only the
attributes relevant to the migration in order to not rely as much on the
codebase being in sync with the database schema.
Thibaut Girka