Conflicts:
- app/models/status.rb
- app/services/remove_status_service.rb
- db/schema.rb
All conflicts were due to the addition of a `deleted_at` attribute
to Statuses and reworked database indexes.
* Add soft delete for statuses to allow them to appear instant
* Allow reporting soft-deleted statuses and show them in the admin UI
* Change index for getting an account's statuses
* Add automatic blocklist display in /about/blocks
Inspired by https://github.com/Gargron/mastodon.social-misc
* Add admin option to set who can see instance blocks
* Normalize locales files
* Rename “Sandbox” to “Silence” for consistency
* Disable /about/blocks when in whitelist mode
* Optionally display rationale for domain blocks
* Only display domain blocks that have user-facing limitations, and order them
* Redesign table of blocked domains to better handle long domain names and rationales
* Change domain blocks ordering now that rationales aren't displayed right away
* Only show explanation for block severities actually in use
* Reword instance block explanations and add disclaimer for public fetch mode
* Add database columns for adding notes to domain blocks/restrctions
* Add admin UI to set private and public comments when blocking a domain
* Add text for private and public comments on domain blocks
* Show domain block comments in admin UI
* Add comments to the domain block undo page
* Make UnblockDomainService more robust regarding upgraded domain blocks
* Allow editing domain blocks
* Rename button from “undo domain block” to “view domain block” in account admin UI
* Change test to unsilence silenced users from upgraded blocks
* Fix account tags not being saved correctly
Regression from f371b32
Fix Tag#discoverable not returning tags where listable is nil instead of true
Add notice when saving hashtags in admin UI
Change public hashtag and directory pages to return 404 for forbidden tags
* Remove unused locale string
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
* Add a spam check
* Use Nilsimsa to generate locality-sensitive hashes and compare using Levenshtein distance
* Add more tests
* Add exemption when the message is a reply to something that mentions the sender
* Use Nilsimsa Compare Value instead of Levenshtein distance
* Use MD5 for messages shorter than 10 characters
* Add message to automated report, do not add non-public statuses to
automated report, add trust level to accounts and make unsilencing
raise the trust level to prevent repeated spam checks on that account
* Expire spam check data after 3 months
* Add support for local statuses, reduce expiration to 1 week, always create a report
* Add content warnings to the spam check and exempt empty statuses
* Change Nilsimsa threshold to 95 and make sure removed statuses are removed from the spam check
* Add all matched statuses into automatic report
* Remove Salmon and PubSubHubbub endpoints
* Add error when trying to follow OStatus accounts
* Fix new accounts not being created in ResolveAccountService
* Record account suspend/silence time and keep track of domain blocks
* Also unblock users who were suspended/silenced before dates were recorded
* Add tests
* Keep track of suspending date for users suspended through the CLI
* Show accurate number of accounts that would be affected by unsuspending an instance
* Change migration to set silenced_at and suspended_at
* Revert "Also unblock users who were suspended/silenced before dates were recorded"
This reverts commit a015c65d2d1e28c7b7cfab8b3f8cd5fb48b8b71c.
* Switch from using suspended and silenced to suspended_at and silenced_at
* Add post-deployment migration script to remove `suspended` and `silenced` columns
* Use Account#silence! and Account#suspend! instead of updating the underlying property
* Add silenced_at and suspended_at migration to post-migration
* Change account fabricator to translate suspended and silenced attributes
* Minor fixes
* Make unblocking domains always retroactive
* When trying to block an already-blocked domain, provide a link to the block
* Fix styling for links in flash messages
* Allow blocks to be upgraded but not downgraded
Conflicts:
- app/views/admin/pending_accounts/index.html.haml
No real conflict, upstream changes too close to glitch-specific
theming system changes.
- config/navigation.rb
Upstream redesigned the settings navigation, took those changes
and re-inserted the flavours menu.
* Add "why do you want to join" field to invite requests
Fix#10512
* Remove unused translations
* Fix broken registrations when no invite request text is submitted
* Revert "Fix filtering of favourited_by, reblogged_by, followers and following (#10447)"
This reverts commit 120544067f.
* Revert "Hide blocking accounts from blocked users (#10442)"
This reverts commit 62bafa20a1.
* Improve blocked view of profiles
- Change "You are blocked" to "Profile unavailable"
- Hide following/followers in API when blocked
- Disable follow button and show "Profile unavailable" on public profile as well
* Update Japanese translations.
run yarn manage:translations && i18n-tasks add-missing
* Update Japanese translations.
* Fix mistake
* Change to be concise.
Conflicts:
- app/controllers/admin/settings_controller.rb
- app/models/form/admin_settings.rb
Conflicts caused by upstream refactoring, while we have
flavours and skins, with the flavour_and_skin pseudo-setting.
Red crosses implied that it was bad/unexpected that certain features
were not enabled. In reality, they are options, so showing a green
or grey power-off icon is more appropriate.
Add status of timeline preview as well
Fix sample accounts changing too frequently due to wrong query
Sample accounts are intended to be sorted by popularity
Conflicts:
- config/locales/en.yml
Conflict caused by the glitch-soc-specific “flavour” string being too close
to the newly introduced “identity_proofs” string. Just included both.
* 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
Conflicts:
- app/controllers/accounts_controller.rb
- app/controllers/follower_accounts_controller.rb
- app/controllers/statuses_controller.rb
All conflicts caused by the additional `use_pack` used for glitch-soc's theming
system.
Conflicts:
- app/controllers/settings/follower_domains_controller.rb
Removed upstream. Did the same here. Maybe we should not have?
- config/locales/en.yml
Upstream removed the “Authorized followers” page and associated
translations. This is too close in the file to our glitch-soc-specific
“flavour” string. No actual conflict.
- config/locales/ja.yml
Same as above.
- config/locales/pl.yml
Same as above.
- config/navigation.rb
No real conflict. New route added too close to the glitch-soc-specific
“flavours” one.
- config/webpack/configuration.js
Upstream refactored the webpack(er) configuration quite a bit.
Tried to keep up.
- config/webpack/loaders/babel.js
Upstream refactored the webpack(er) configuration quite a bit.
Tried to keep up.
The contents of this file have been moved to package.json.
- config/webpack/shared.js
Upstream refactored the webpack(er) configuration quite a bit.
Tried to keep up.
- config/webpacker.yml
Upstream refactored the webpack(er) configuration quite a bit.
Tried to keep up.
- jest.config.js
The contents of this file have been moved to package.json.
- package.json
Upstream refactored the webpack(er) configuration quite a bit.
Tried to keep up.
- yarn.lock
Upstream refactored the webpack(er) configuration quite a bit.
Tried to keep up.
* 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
Conflicts:
- app/controllers/oauth/authorized_applications_controller.rb
Two changes too close to each other
- app/controllers/settings/sessions_controller.rb
- app/lib/user_settings_decorator.rb
Two changes too close to each other
- app/models/media_attachment.rb
New changes too close to glitch-soc only changes.
- app/models/user.rb
Two changes too close to each other.
- app/services/remove_status_service.rb
Kept direct timeline code which had been removed upstream.
- app/views/settings/preferences/show.html.haml
Two changes too close to each other.
- config/locales/en.yml
Introduction of a new string too close to glitch-soc-only's “flavour”
- config/locales/ja.yml
Introduction of a new string too close to glitch-soc-only's “flavour”
- config/locales/pl.yml
Introduction of a new string too close to glitch-soc-only's “flavour”
- config/locales/simple_form.en.yml
Introduction of a new string too close to glitch-soc-only's “skin”
- config/locales/simple_form.pl.yml
Introduction of a new string too close to glitch-soc-only's “skin”
- config/settings.yml
Reverted upstream's decision of enabling posting application by default.
* 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
Conflicts:
- README.md
Kept our version
- app/javascript/mastodon/features/compose/components/compose_form.js
Two changes too close to each other, took both changes
Conflicts:
- .eslintrc.yml
Removed, as upstream removed it.
- app/controllers/admin/statuses_controller.rb
Minor code cleanup when porting one of our features.
- app/models/account.rb
Note length validation has changed upstream.
We now use upstream's validation (dropped legacy glitch-soc
account metadata stuff) but with configurable limit.
- app/services/post_status_service.rb
Upstream has added support for scheduled toots, refactoring
the code a bit. Adapted our changes to this refactoring.
- app/views/stream_entries/_detailed_status.html.haml
Not a real conflict, changes too close.
- app/views/stream_entries/_simple_status.html.haml
Not a real conflict, changes too close.
* Change remote interaction dialog to use specific actions
Instead of just "interact", use different strings based on whether
it's a reply, reblog or favourite. Add explanation why the step
is necessary in the first place
* Remove obsolete strings
* 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
Eugen Rochko