2023-05-31 23:43:39 +02:00
|
|
|
import { IntlMessageFormat } from 'intl-messageformat';
|
2023-05-23 17:15:17 +02:00
|
|
|
import { defineMessages } from 'react-intl';
|
|
|
|
|
|
|
|
import { unescapeHTML } from '../utils/html';
|
|
|
|
import { requestNotificationPermission } from '../utils/notifications';
|
|
|
|
|
2024-09-24 19:02:36 +02:00
|
|
|
import { fetchFollowRequests } from './accounts';
|
2018-03-24 21:06:27 +09:00
|
|
|
import {
|
|
|
|
importFetchedAccount,
|
|
|
|
} from './importer';
|
2020-05-29 16:14:16 +02:00
|
|
|
import { submitMarkers } from './markers';
|
2023-11-03 16:00:03 +01:00
|
|
|
import { notificationsUpdate } from "./notifications_typed";
|
2023-09-12 18:27:01 +02:00
|
|
|
import { register as registerPushNotifications } from './push_notifications';
|
2016-11-20 19:39:18 +01:00
|
|
|
|
2023-11-03 16:00:03 +01:00
|
|
|
export * from "./notifications_typed";
|
|
|
|
|
2018-12-16 05:56:41 +01:00
|
|
|
export const NOTIFICATIONS_FILTER_SET = 'NOTIFICATIONS_FILTER_SET';
|
|
|
|
|
2020-12-15 18:43:54 +01:00
|
|
|
export const NOTIFICATIONS_SET_BROWSER_SUPPORT = 'NOTIFICATIONS_SET_BROWSER_SUPPORT';
|
|
|
|
export const NOTIFICATIONS_SET_BROWSER_PERMISSION = 'NOTIFICATIONS_SET_BROWSER_PERMISSION';
|
2020-10-13 00:37:21 +02:00
|
|
|
|
2017-06-23 23:05:04 +09:00
|
|
|
defineMessages({
|
2017-05-12 14:46:21 +02:00
|
|
|
mention: { id: 'notification.mention', defaultMessage: '{name} mentioned you' },
|
2018-05-19 14:46:47 +02:00
|
|
|
group: { id: 'notifications.group', defaultMessage: '{count} notifications' },
|
2017-05-12 14:46:21 +02:00
|
|
|
});
|
|
|
|
|
2016-11-21 10:24:50 +01:00
|
|
|
export function updateNotifications(notification, intlMessages, intlLocale) {
|
2017-01-02 14:09:57 +01:00
|
|
|
return (dispatch, getState) => {
|
2018-04-13 01:20:04 +02:00
|
|
|
const showAlert = getState().getIn(['settings', 'notifications', 'alerts', notification.type], true);
|
|
|
|
const playSound = getState().getIn(['settings', 'notifications', 'sounds', notification.type], true);
|
2018-07-07 19:31:19 +02:00
|
|
|
|
|
|
|
let filtered = false;
|
|
|
|
|
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 09:42:13 +02:00
|
|
|
if (['mention', 'status'].includes(notification.type) && notification.status.filtered) {
|
|
|
|
const filters = notification.status.filtered.filter(result => result.filter.context.includes('notifications'));
|
2018-07-07 19:31:19 +02:00
|
|
|
|
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 09:42:13 +02:00
|
|
|
if (filters.some(result => result.filter.filter_action === 'hide')) {
|
2019-06-18 18:23:08 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 09:42:13 +02:00
|
|
|
filtered = filters.length > 0;
|
2018-07-07 19:31:19 +02:00
|
|
|
}
|
2017-01-17 20:09:03 +01:00
|
|
|
|
2021-08-25 11:46:29 -04:00
|
|
|
if (['follow_request'].includes(notification.type)) {
|
|
|
|
dispatch(fetchFollowRequests());
|
|
|
|
}
|
|
|
|
|
2020-05-29 16:14:16 +02:00
|
|
|
dispatch(submitMarkers());
|
|
|
|
|
2025-01-06 19:22:07 +01:00
|
|
|
// `notificationsUpdate` is still used in `user_lists` and `relationships` reducers
|
|
|
|
dispatch(importFetchedAccount(notification.account));
|
|
|
|
dispatch(notificationsUpdate({ notification, playSound: playSound && !filtered}));
|
2016-11-21 10:24:50 +01:00
|
|
|
|
|
|
|
// Desktop notifications
|
2018-07-07 19:31:19 +02:00
|
|
|
if (typeof window.Notification !== 'undefined' && showAlert && !filtered) {
|
2016-11-21 10:59:59 +01:00
|
|
|
const title = new IntlMessageFormat(intlMessages[`notification.${notification.type}`], intlLocale).format({ name: notification.account.display_name.length > 0 ? notification.account.display_name : notification.account.username });
|
2017-05-12 22:03:43 -04:00
|
|
|
const body = (notification.status && notification.status.spoiler_text.length > 0) ? notification.status.spoiler_text : unescapeHTML(notification.status ? notification.status.content : '');
|
2016-11-21 10:24:50 +01:00
|
|
|
|
2017-05-11 20:34:05 +09:00
|
|
|
const notify = new Notification(title, { body, icon: notification.account.avatar, tag: notification.id });
|
2018-04-13 01:20:04 +02:00
|
|
|
|
2017-05-11 20:34:05 +09:00
|
|
|
notify.addEventListener('click', () => {
|
|
|
|
window.focus();
|
|
|
|
notify.close();
|
|
|
|
});
|
2016-11-21 10:59:59 +01:00
|
|
|
}
|
2016-11-20 19:39:18 +01:00
|
|
|
};
|
2022-12-18 10:51:37 -05:00
|
|
|
}
|
2016-11-20 19:39:18 +01:00
|
|
|
|
2018-05-18 02:32:35 +02:00
|
|
|
const noOp = () => {};
|
|
|
|
|
2020-10-13 00:37:21 +02:00
|
|
|
// Browser support
|
|
|
|
export function setupBrowserNotifications() {
|
|
|
|
return dispatch => {
|
|
|
|
dispatch(setBrowserSupport('Notification' in window));
|
|
|
|
if ('Notification' in window) {
|
|
|
|
dispatch(setBrowserPermission(Notification.permission));
|
|
|
|
}
|
|
|
|
|
|
|
|
if ('Notification' in window && 'permissions' in navigator) {
|
|
|
|
navigator.permissions.query({ name: 'notifications' }).then((status) => {
|
|
|
|
status.onchange = () => dispatch(setBrowserPermission(Notification.permission));
|
2020-11-24 01:35:14 +09:00
|
|
|
}).catch(console.warn);
|
2020-10-13 00:37:21 +02:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
export function requestBrowserPermission(callback = noOp) {
|
|
|
|
return dispatch => {
|
|
|
|
requestNotificationPermission((permission) => {
|
|
|
|
dispatch(setBrowserPermission(permission));
|
|
|
|
callback(permission);
|
2023-09-12 18:27:01 +02:00
|
|
|
|
|
|
|
if (permission === 'granted') {
|
|
|
|
dispatch(registerPushNotifications());
|
|
|
|
}
|
2020-10-13 00:37:21 +02:00
|
|
|
});
|
|
|
|
};
|
2022-12-18 10:51:37 -05:00
|
|
|
}
|
2020-10-13 00:37:21 +02:00
|
|
|
|
|
|
|
export function setBrowserSupport (value) {
|
|
|
|
return {
|
|
|
|
type: NOTIFICATIONS_SET_BROWSER_SUPPORT,
|
|
|
|
value,
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
export function setBrowserPermission (value) {
|
|
|
|
return {
|
|
|
|
type: NOTIFICATIONS_SET_BROWSER_PERMISSION,
|
|
|
|
value,
|
|
|
|
};
|
|
|
|
}
|