* 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
* Process incoming poll tallies update
* Send Update on poll vote
* Do not send Updates for a poll more often than once every 3 minutes
* Include voters in people to notify of results update
* Schedule closing poll worker on poll creation
* Add new notification type for ending polls
* Add front-end support for ended poll notifications
* Fix UpdatePollSerializer
* Fix Updates not being triggered by local votes
* Fix tests failure
* Fix web push notifications for closing polls
* Minor cleanup
* Notify voters of both remote and local polls when those close
* Fix delivery of poll updates to mentioned accounts and voters
* Update babel-eslint to version 8.2.3
* Update eslint to version 4.19.1
* Update eslint-plugin-promise to version 3.8.0
* Update eslint-plugin-react to version 7.8.2
* Upgrade eslint-plugin-jsx-a11y to version 6.0.3
* yarn test:lint --fix
> Good lord what is happening in there
Previously the contents of the Web Push API payloads closely resembled the structure of JavaScript's [Notification](https://developer.mozilla.org/en-US/docs/Web/API/Notification). But now that the API is open to non-browser apps, and given that there is no required coupling between contents of the payload and a Notification object, here is how I changed the payload:
```json
{
"access_token": "...",
"preferred_locale": "en",
"notification_id": "12345",
"notification_type": "follow",
"title": "So and so followed you",
"body": "This is my bio",
"icon": "https://example.com/avatar.png"
}
```
The title, body and icon attributes are included as a fallback so you can construct a minimal notification if you cannot perform a network request to the API to get more data.
offline-plugin depends on webpack.optimize.UglifyJsPlugin, which is an
alias of uglifyjs-webpack-plugin v0.4.6. uglifyjs-webpack-plugin v0.4.6
uses uglify-js 2.8.29, which is not compatible with async function.
`Response.prototype.clone()` must be called before the response used.
This fixes an error from ServiceWorker and failing to load image when the
image is not cached.
* Refactor Web::PushSubscription, remove welcome message
* Add missing helper
* Use locale of the receiver on push notifications (#4519)
* Remove unused translations
* Fix dir on notifications
* fix(web_push_notification): Do not hard reload tab
* fix(web_push_notification_worker): Guard against null subscription
* refactor: Incorporate pull request feedback
Bèr Kessels
