| Age | Commit message (Collapse) | Author |
|---|
|
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/models/status.rb
- db/schema.rb
Both conflicts are caused by us having extra database columns.
|
|
* 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:
- .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.
|
|
* Not to skip executable specs
* Combine specs
Combine specs to one to reduce multiple slow http post.
|
|
Fix #340
|
|
Conflicts manually resolved:
- app/services/post_status_service.rb
- config/locales/simple_form.pl.yml
- config/routes.rb
- config/webpack/loaders/sass.js
- config/webpack/shared.js
- package.json
- yarn.lock
|
|
* 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
|
|
Conflicts:
- app/controllers/admin/base_controller.rb
Some refactoring made upstream, no real conflict.
- app/javascript/mastodon/features/compose/components/compose_form.js
Updated using upstream's code but using maxChars instead of the
hardcoded length of 500 characters per toot.
- app/javascript/styles/mastodon/components.scss
Upstream redesigned the onboarding modal. Not sure why we had a
conflict there.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* cleanup pass
* undo mistakes
* fixed.
* revert
|
|
* 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:
app/lib/user_settings_decorator.rb
app/models/user.rb
app/serializers/initial_state_serializer.rb
app/views/stream_entries/_simple_status.html.haml
config/locales/simple_form.en.yml
config/locales/simple_form.ja.yml
config/locales/simple_form.pl.yml
config/routes.rb
|
|
* 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
|
|
Conflicts:
app/controllers/api/v1/mutes_controller.rb
config/locales/simple_form.pl.yml
|
|
Fixes #8463
|
|
* Update Rails
* fix Update Rails
|
|
* Update Rails
* fix Update Rails
|
|
|
|
Conflicts:
README.md
app/controllers/statuses_controller.rb
app/lib/feed_manager.rb
config/navigation.rb
spec/lib/feed_manager_spec.rb
Conflicts were resolved by taking both versions for each change.
This means the two filter systems (glitch-soc's keyword mutes and tootsuite's
custom filters) are in place, which will be changed in a follow-up commit.
|
|
* Add more granular OAuth scopes
* Add human-readable descriptions of the new scopes
* Ensure new scopes look good on the app UI
* Add tests
* Group scopes in screen and color-code dangerous ones
* Fix wrong extra scope
|
|
* Re-add follow recommendations API
GET /api/v1/suggestions
Removed in 8efa081f210d72ed450c39ac4cde0fd84fb3d3fb due to Neo4J
dependency. The algorithm uses triadic closures, takes into account
suspensions, blocks, mutes, domain blocks, excludes locked and moved
accounts, and prefers more recently updated accounts.
* Track interactions with people you don't follow
Replying to, favouriting and reblogging someone you're not following
will make them show up in follow recommendations. The interactions
have different weights:
- Replying is 1
- Favouriting is 10 (decidedly positive interaction, but private)
- Reblogging is 20
Following them, muting or blocking will remove them from the list,
obviously.
* Remove triadic closures, ensure potential friendships are trimmed
|
|
* Add keyword filtering
GET|POST /api/v1/filters
GET|PUT|DELETE /api/v1/filters/:id
- Irreversible filters can drop toots from home or notifications
- Other filters can hide toots through the client app
- Filters use a phrase valid in particular contexts, expiration
* Make sure expired filters don't get applied client-side
* Add missing API methods
* Remove "regex filter" from column settings
* Add tests
* Add test for FeedManager
* Add CustomFilter test
* Add UI for managing filters
* Add streaming API event to allow syncing filters
* Fix tests
|
|
Conflicts:
app/models/status.rb
The conflict in the Status model was due to
https://github.com/tootsuite/mastodon/commit/5bf500338478f819a65d25636a0af61a482972d3.
It was resolved by accepting tootsuite's changes.
|
|
* Small refactoring of status_finder_spec
* Add tests for embeds_controller
|
|
Conflicts:
app/controllers/invites_controller.rb
app/serializers/initial_state_serializer.rb
config/locales/ko.yml
|
|
- POST /api/v1/push/subscription
- PUT /api/v1/push/subscription
- DELETE /api/v1/push/subscription
- New OAuth scope: "push" (required for the above methods)
|
|
Conflicts:
.travis.yml
Gemfile.lock
README.md
app/controllers/settings/follower_domains_controller.rb
app/controllers/statuses_controller.rb
app/javascript/mastodon/locales/ja.json
app/lib/feed_manager.rb
app/models/media_attachment.rb
app/models/mute.rb
app/models/status.rb
app/services/mute_service.rb
app/views/home/index.html.haml
app/views/stream_entries/_simple_status.html.haml
config/locales/ca.yml
config/locales/en.yml
config/locales/es.yml
config/locales/fr.yml
config/locales/nl.yml
config/locales/pl.yml
config/locales/pt-BR.yml
config/themes.yml
|
|
|
|
|
|
Conflicts:
app/serializers/initial_state_serializer.rb
The glitch flavour isn't yet pulling custom emoji data on its own (see
https://github.com/tootsuite/mastodon/pull/7047). Once that gets into
the glitch flavour, we can eliminate the custom_emojis load.
|
|
rest api (#6789)
* Enable updating additional account information from user preferences via rest api
Resolves #6553
* Pacify rubocop
* Decoerce incoming settings in UserSettingsDecorator
* Create user preferences hash directly from incoming credentials instead of going through ActionController::Parameters
* Clean up user preferences update
* Use ActiveModel::Type::Boolean instead of manually checking stringified number equivalence
|
|
# Conflicts:
# app/controllers/settings/exports_controller.rb
# app/models/media_attachment.rb
# app/models/status.rb
# app/views/about/show.html.haml
# docker_entrypoint.sh
# spec/views/about/show.html.haml_spec.rb
|
|
It was merge when it needed to be deep_merge. And added some tests
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Break out nested relationship API keys
This closes #5856 by restoring the existing behavior of the `muting`
and `following` keys (returning booleans rather than truthy or false).
It adds `showing_reblogs` and `muting_notifications` keys:
* `showing_reblogs` returns true if:
1. You've requested to follow the user, with reblogs shown, or
2. You are following the user, with reblogs shown.
* `muting_notifications` returns true if you have muted the user and
their notifications as well.
* Rubocop fix
* Fix pulling reblog/mute status from relationships
I could swear this had passed tests before, but apparently not.
Works now.
* More test fixes
Really, you'd expect this to be more straightforward.
|
|
* Allow hiding of reblogs from followed users
This adds a new entry to the account menu to allow users to hide
future reblogs from a user (and then if they've done that, to show
future reblogs instead).
This does not remove or add historical reblogs from/to the user's
timeline; it only affects new statuses.
The API for this operates by sending a "reblogs" key to the follow
endpoint. If this is sent when starting a new follow, it will be
respected from the beginning of the follow relationship (even if
the follow request must be approved by the followee). If this is
sent when a follow relationship already exists, it will simply
update the existing follow relationship. As with the notification
muting, this will now return an object ({reblogs: [true|false]}) or
false for each follow relationship when requesting relationship
information for an account. This should cause few issues due to an
object being truthy in many languages, but some modifications may
need to be made in pickier languages.
Database changes: adds a show_reblogs column (default true,
non-nullable) to the follows and follow_requests tables. Because
these are non-nullable, we use the existing MigrationHelpers to
perform this change without locking those tables, although the
tables are likely to be small anyway.
Tests included.
See also <https://github.com/glitch-soc/mastodon/pull/212>.
* Rubocop fixes
* Code review changes
* Test fixes
This patchset closes #648 and resolves #3271.
* Rubocop fix
* Revert reblogs defaulting in argument, fix tests
It turns out we needed this for the same reason we needed it in muting:
if nil gets passed in somehow (most usually by an API client not passing
any value), we need to detect and handle it.
We could specify a default in the parameter and then also catch nil, but
there's no great reason to duplicate the default value.
|
