When running `bundle exec rails assets:precompile` inside docker build, with `site_title` it requires a DB connection, where as `Setting.default_settings['site_title']` doesn't.
Running a docker build without this commit, the following error is reported:
```
...
[build-hometown:5785] ** Execute assets:generate_static_pages
[build-hometown:5786] rails aborted!
[build-hometown:5787] ActionView::Template::Error: could not connect to server: Connection refused
[build-hometown:5788] Is the server running on host "localhost" (127.0.0.1) and accepting
[build-hometown:5789] TCP/IP connections on port 5432?
[build-hometown:5790] could not connect to server: Cannot assign requested address
[build-hometown:5791] Is the server running on host "localhost" (::1) and accepting
[build-hometown:5792] TCP/IP connections on port 5432?
[build-hometown:5793] /opt/mastodon/vendor/bundle/ruby/2.6.0/gems/pg-1.1.4/lib/pg.rb:56:in `initialize'
[build-hometown:5794] /opt/mastodon/vendor/bundle/ruby/2.6.0/gems/pg-1.1.4/lib/pg.rb:56:in `new'
[build-hometown:5795] /opt/mastodon/vendor/bundle/ruby/2.6.0/gems/pg-1.1.4/lib/pg.rb:56:in `connect'
...
```
I can provide the full trace logs if needed.
* Add follow_request notification type
The notification type already existed in the backend but was never pushed
to the front-end. This also means translation strings were also available
for the backend, from the notification mailer.
Unlike other notification types, these are off by default, to match what
I remember of Gargron's view on the topic: that follow requests should not
clutter notifications and should instead be reviewed at the user's own
leisure in the dedicated column.
Since follow requests have their own column, I've deemed it unnecessary to
add a specific tab for them in the notification quick filter.
* Show follow request link in single-column if there are pending requests, even if account isn't locked
* Push follow requests from notifications to the follow_requests list
* Offer to accept or reject follow request from the notification
* Redesign follow request notification
Before this patch, if remote poll options have leading or trailing spaces,
the information stored locally won't match them, causing federated voting to
fail.
Before this moment relationships managing page was using strings from
other context - from counters, but in order for translators to be able
to translate it relatively to the page, it must use separate strings.
I've split the strings for "Following" and "Followers" and put them to
"relationships" keyset in localization file. This should solve this
issue.
Fixes#10863
When authenticating via OAuth, the resource owner password grant
strategy is allowed by Mastodon, but (without this PR), it does not
attempt to authenticate against LDAP or PAM. As a result, LDAP or PAM
authenticated users cannot sign in to Mastodon with their
email/password credentials via OAuth (for instance, for native/mobile
app users).
This PR fleshes out the authentication strategy supplied to doorkeeper
in its initializer by looking up the user with LDAP and/or PAM when
devise is configured to use LDAP/PAM backends. It attempts to follow the
same logic as the Auth::SessionsController for handling email/password
credentials.
Note #1: Since this pull request affects an initializer, it's unclear
how to add test automation.
Note #2: The PAM authentication path has not been manually tested. It
was added for completeness sake, and it is hoped that it can be manually
tested before merging.
* Fix lost focus after modal closes
Regression caused by the use of the wicg-inert polyfill
* Fix regression introduced by wicg-inert
* Catch errors to please CodeClimate
Counter size is currently set to strict 33.3% width, but with it
counter may break in other languages than English. For example it is
already broken on Gargron's profile on mastodon.social using Russian
locale.
This commit changes "width" to "min-width", so counters still displayed
correctly, but if they need more width to fit text, they are now allowed
to take as many width as they need.
Currently notifications page seems a bit cluttered with no clear
separation between e-mail and filtering settings. This commit tries to
address them by adding clear separation with headers, hints and removing
continuously reused texts for events checkboxes.
The arguments were passed to the wrong function… also, there is no
need to have a conditional decrementation: failure to upload means
we marked an upload as pending, in all cases.
If a poll contains empty options (which is apparently possible on Pleroma),
it is created without them. However, the poll update code doesn't filter
empty options, and thus:
1. Clear known votes, as it assumes the set of options has changed
2. Errors out because it tries adding empty options, which fails validation
This commit fixes that by filtering them out the same way they are filtered
out at poll creation time.
