Addresses #1451 which notes the emoji picker is too light. I agree, so I submit this adjustment.
Changes:
Changed the background to a darkened version of another system color
* Replace column margin with padding
This improves horizontal scrolling behaviour significantly; scrolled flex elements are... a little weird.
* Move clear column button styling to css
* Replace column margin with padding
This improves horizontal scrolling behaviour significantly; scrolled flex elements are... a little weird.
* Move clear column button styling to css
Sign-in redirects you back to last visited URL, but in case of API requests,
this sometimes redirected users to an API URL that, of course, greeted them
with an {"error":"The access token is invalid"}
Sign-in redirects you back to last visited URL, but in case of API requests,
this sometimes redirected users to an API URL that, of course, greeted them
with an {"error":"The access token is invalid"}
The goal of this change is to enhance Mastodon's handling of remote domains
for which the APIs reside on a different host (see issue #1032).
Indeed, when a remote user unknown to Mastodon is mentionned, only its profile
URL (e.g. https://social.example.org/users/User) is known, and Mastodon has to
build a @username@domain handle for it. To do so, Mastodon fetches the user's
atom feed (e.g., https://social.example.org/users/User.atom) and uses its
content to get the username part of the handle, and the URL's host part to
build the domain (e.g., @User@social.example.org). This handle is then used
for a Webfinger request.
In the case where example.org serves the Webfinger info for @User@example.org
and all feeds and APIs are hosted at social.example.org, Mastodon will still
build @User@social.example.org and fail at resolving the account's details
through Webfinger.
This patch changes this behaviour by using the author's email address from
the atom feed to build the handle. In Mastodon-generated atom feeds, the
email address is always the handle it expects for federation.
The goal of this change is to enhance Mastodon's handling of remote domains
for which the APIs reside on a different host (see issue #1032).
Indeed, when a remote user unknown to Mastodon is mentionned, only its profile
URL (e.g. https://social.example.org/users/User) is known, and Mastodon has to
build a @username@domain handle for it. To do so, Mastodon fetches the user's
atom feed (e.g., https://social.example.org/users/User.atom) and uses its
content to get the username part of the handle, and the URL's host part to
build the domain (e.g., @User@social.example.org). This handle is then used
for a Webfinger request.
In the case where example.org serves the Webfinger info for @User@example.org
and all feeds and APIs are hosted at social.example.org, Mastodon will still
build @User@social.example.org and fail at resolving the account's details
through Webfinger.
This patch changes this behaviour by using the author's email address from
the atom feed to build the handle. In Mastodon-generated atom feeds, the
email address is always the handle it expects for federation.
* Use HTTP Accept-Language to detect locale
* Fix gem order to comply with codeclimate
* Sort gem to comply with rubocop
* I18n.default_locale fallback when there is no accept-language header
* Use HTTP Accept-Language to detect locale
* Fix gem order to comply with codeclimate
* Sort gem to comply with rubocop
* I18n.default_locale fallback when there is no accept-language header
* Put a useful message for new admins on /about/more
I totally failed to realize this file was just defaults. I think
this message would be a good default for people like me.
* Revert default site description, expand comment
This will keep setup-related stuff from leaking into public views,
while still hopefully keeping over-eager admins from editing this
file unnecessarily before RTFMing. (e.g., me)
* Put a useful message for new admins on /about/more
I totally failed to realize this file was just defaults. I think
this message would be a good default for people like me.
* Revert default site description, expand comment
This will keep setup-related stuff from leaking into public views,
while still hopefully keeping over-eager admins from editing this
file unnecessarily before RTFMing. (e.g., me)
* Allow users to update their Account in the API
It would be nice for API clients to be able to allow users to update
their accounts without having to wrap Mastodon in a web view. This patch
adds an API endpoint to let users submit a PATCH for their account.
Signed-off-by: David Celis <me@davidcel.is>
* Add /api/v1/accounts/update_credentials to the API docs
Signed-off-by: David Celis <me@davidcel.is>
* Allow users to update their Account in the API
It would be nice for API clients to be able to allow users to update
their accounts without having to wrap Mastodon in a web view. This patch
adds an API endpoint to let users submit a PATCH for their account.
Signed-off-by: David Celis <me@davidcel.is>
* Add /api/v1/accounts/update_credentials to the API docs
Signed-off-by: David Celis <me@davidcel.is>
* Update confirmation_instructions.fr.html.erb
consistency across the French translation
* Update
consistency across the French translation
* Update fr.yml
a bunch of consistency across the French translation + a few typos
* Update doorkeeper.fr.yml
consistency across the French translation (punctuation)
* Update confirmation_instructions.fr.html.erb
consistency across the French translation
* Update
consistency across the French translation
* Update fr.yml
a bunch of consistency across the French translation + a few typos
* Update doorkeeper.fr.yml
consistency across the French translation (punctuation)
* Clean up SQL output in Tag and Account search methods
* Add basic coverage for Tag.search_for
* Add coverage for Account.search_for
* Add coverage for Account.advanced_search_for
