2020-04-29 18:44:27 +03:00
|
|
|
const _ = require('lodash');
|
2021-05-27 16:53:55 +03:00
|
|
|
|
2021-07-02 18:00:33 +03:00
|
|
|
const api = require('./api');
|
2020-05-27 20:47:53 +03:00
|
|
|
const config = require('../shared/config');
|
2020-05-28 13:57:02 +03:00
|
|
|
const urlUtils = require('./../shared/url-utils');
|
2021-06-23 14:01:43 +03:00
|
|
|
const jobsService = require('./services/jobs');
|
2021-05-27 16:53:55 +03:00
|
|
|
|
2021-06-16 14:54:14 +03:00
|
|
|
const request = require('@tryghost/request');
|
2021-06-16 11:36:58 +03:00
|
|
|
const ghostVersion = require('@tryghost/version');
|
2021-06-03 12:24:19 +03:00
|
|
|
const UpdateCheckService = require('@tryghost/update-check-service');
|
2014-01-03 19:50:03 +04:00
|
|
|
|
2021-06-23 17:37:49 +03:00
|
|
|
/**
|
2021-07-02 18:04:32 +03:00
|
|
|
* Initializes and triggers update check
|
2021-06-23 17:37:49 +03:00
|
|
|
*
|
|
|
|
* @returns {Promise<any>}
|
|
|
|
*/
|
2021-07-02 18:04:32 +03:00
|
|
|
module.exports = async () => {
|
2021-05-27 16:53:55 +03:00
|
|
|
const allowedCheckEnvironments = ['development', 'production'];
|
Update Notification improvements (#9123)
closes #5071
- Remove hardcoded notification in admin controller
- NOTE: update check notifications are no longer blocking the admin rendering
- this is one of the most import changes
- we remove the hardcoded release message
- we also remove adding a notification manually in here, because this will work differently from now on
-> you receive a notification (release or custom) in the update check module and this module adds the notification as is to our database
- Change default core settings keys
- remove displayUpdateNotification
-> this was used to store the release version number send from the UCS
-> based on this value, Ghost creates a notification container with self defined values
-> not needed anymore
- rename seenNotifications to notifications
-> the new notifications key will hold both
1. the notification from the USC
2. the information about if a notification was seen or not
- this key hold only one release notification
- and n custom notifications
- Update Check Module: Request to the USC depends on the privacy configuration
- useUpdateCheck: true -> does a checkin in the USC (exposes data)
- useUpdateCheck: false -> does only a GET query to the USC (does not expose any data)
- make the request handling dynamic, so it depends on the flag
- add an extra logic to be able to define a custom USC endpoint (helpful for testing)
- add an extra logic to be able to force the request to the service (helpful for testing)
- Update check module: re-work condition when a check should happen
- only if the env is not correct
- remove deprecated config.updateCheck
- remove isPrivacyDisabled check (handled differently now, explained in last commit)
- Update check module: remove `showUpdateNotification` and readability
- showUpdateNotification was used in the admin controller to fetch the latest release version number from the db
- no need to check against semver in general, the USC takes care of that (no need to double check)
- improve readability of `nextUpdateCheck` condition
- Update check module: refactor `updateCheckResponse`
- remove db call to displayUpdateNotification, not used anymore
- support receiving multiple custom notifications
- support custom notification groups
- the default group is `all` - this will always be consumed
- groups can be extended via config e.g. `notificationGroups: ['migration']`
- Update check module: refactor createCustomNotification helper
- get rid of taking over notification duplication handling (this is not the task of the update check module)
- ensure we have good fallback values for non present attributes in a notification
- get rid of semver check (happens in the USC) - could be reconsidered later if LTS is gone
- Refactor notification API
- reason: get rid of in process notification store
-> this was an object hold in process
-> everything get's lost after restart
-> not helpful anymore, because imagine the following case
-> you get a notification
-> you store it in process
-> you mark this notification as seen
-> you restart Ghost, you will receive the same notification on the next check again
-> because we are no longer have a separate seen notifications object
- use database settings key `notification` instead
- refactor all api endpoints to support reading and storing into the `notifications` object
- most important: notification deletion happens via a `seen` property (the notification get's physically deleted 3 month automatically)
-> we have to remember a seen property, because otherwise you don't know which notification was already received/seen
- Add listener to remove seen notifications automatically after 3 month
- i just decided for 3 month (we can decrease?)
- at the end it doesn't really matter, as long as the windows is not tooooo short
- listen on updates for the notifications settings
- check if notification was seen and is older than 3 month
- ignore release notification
- Updated our privacy document
- Updated docs.ghost.org for privacy config behaviour
- contains a migration script to remove old settings keys
2018-01-09 17:20:00 +03:00
|
|
|
|
|
|
|
// CASE: The check will not happen if your NODE_ENV is not in the allowed defined environments.
|
|
|
|
if (_.indexOf(allowedCheckEnvironments, process.env.NODE_ENV) === -1) {
|
2021-05-26 15:06:06 +03:00
|
|
|
return;
|
Update Notification improvements (#9123)
closes #5071
- Remove hardcoded notification in admin controller
- NOTE: update check notifications are no longer blocking the admin rendering
- this is one of the most import changes
- we remove the hardcoded release message
- we also remove adding a notification manually in here, because this will work differently from now on
-> you receive a notification (release or custom) in the update check module and this module adds the notification as is to our database
- Change default core settings keys
- remove displayUpdateNotification
-> this was used to store the release version number send from the UCS
-> based on this value, Ghost creates a notification container with self defined values
-> not needed anymore
- rename seenNotifications to notifications
-> the new notifications key will hold both
1. the notification from the USC
2. the information about if a notification was seen or not
- this key hold only one release notification
- and n custom notifications
- Update Check Module: Request to the USC depends on the privacy configuration
- useUpdateCheck: true -> does a checkin in the USC (exposes data)
- useUpdateCheck: false -> does only a GET query to the USC (does not expose any data)
- make the request handling dynamic, so it depends on the flag
- add an extra logic to be able to define a custom USC endpoint (helpful for testing)
- add an extra logic to be able to force the request to the service (helpful for testing)
- Update check module: re-work condition when a check should happen
- only if the env is not correct
- remove deprecated config.updateCheck
- remove isPrivacyDisabled check (handled differently now, explained in last commit)
- Update check module: remove `showUpdateNotification` and readability
- showUpdateNotification was used in the admin controller to fetch the latest release version number from the db
- no need to check against semver in general, the USC takes care of that (no need to double check)
- improve readability of `nextUpdateCheck` condition
- Update check module: refactor `updateCheckResponse`
- remove db call to displayUpdateNotification, not used anymore
- support receiving multiple custom notifications
- support custom notification groups
- the default group is `all` - this will always be consumed
- groups can be extended via config e.g. `notificationGroups: ['migration']`
- Update check module: refactor createCustomNotification helper
- get rid of taking over notification duplication handling (this is not the task of the update check module)
- ensure we have good fallback values for non present attributes in a notification
- get rid of semver check (happens in the USC) - could be reconsidered later if LTS is gone
- Refactor notification API
- reason: get rid of in process notification store
-> this was an object hold in process
-> everything get's lost after restart
-> not helpful anymore, because imagine the following case
-> you get a notification
-> you store it in process
-> you mark this notification as seen
-> you restart Ghost, you will receive the same notification on the next check again
-> because we are no longer have a separate seen notifications object
- use database settings key `notification` instead
- refactor all api endpoints to support reading and storing into the `notifications` object
- most important: notification deletion happens via a `seen` property (the notification get's physically deleted 3 month automatically)
-> we have to remember a seen property, because otherwise you don't know which notification was already received/seen
- Add listener to remove seen notifications automatically after 3 month
- i just decided for 3 month (we can decrease?)
- at the end it doesn't really matter, as long as the windows is not tooooo short
- listen on updates for the notifications settings
- check if notification was seen and is older than 3 month
- ignore release notification
- Updated our privacy document
- Updated docs.ghost.org for privacy config behaviour
- contains a migration script to remove old settings keys
2018-01-09 17:20:00 +03:00
|
|
|
}
|
2014-04-28 03:28:50 +04:00
|
|
|
|
2021-10-21 11:27:56 +03:00
|
|
|
const {GhostMailer} = require('./services/mail');
|
|
|
|
const ghostMailer = new GhostMailer();
|
|
|
|
|
2021-06-23 17:37:49 +03:00
|
|
|
const updateChecker = new UpdateCheckService({
|
|
|
|
api: {
|
|
|
|
settings: {
|
|
|
|
read: api.settings.read,
|
|
|
|
edit: api.settings.edit
|
2021-06-02 11:36:22 +03:00
|
|
|
},
|
2021-06-23 17:37:49 +03:00
|
|
|
posts: {
|
|
|
|
browse: api.posts.browse
|
2021-06-02 13:08:22 +03:00
|
|
|
},
|
2021-06-23 17:37:49 +03:00
|
|
|
users: {
|
|
|
|
browse: api.users.browse
|
|
|
|
},
|
|
|
|
notifications: {
|
|
|
|
add: api.notifications.add
|
|
|
|
}
|
|
|
|
},
|
|
|
|
config: {
|
|
|
|
mail: config.get('mail'),
|
|
|
|
env: config.get('env'),
|
|
|
|
databaseType: config.get('database').client,
|
|
|
|
checkEndpoint: config.get('updateCheck:url'),
|
|
|
|
isPrivacyDisabled: config.isPrivacyDisabled('useUpdateCheck'),
|
|
|
|
notificationGroups: config.get('notificationGroups'),
|
|
|
|
siteUrl: urlUtils.urlFor('home', true),
|
|
|
|
forceUpdate: config.get('updateCheck:forceUpdate'),
|
|
|
|
ghostVersion: ghostVersion.original
|
|
|
|
},
|
|
|
|
request,
|
2021-07-07 10:29:18 +03:00
|
|
|
sendEmail: ghostMailer.send.bind(ghostMailer)
|
2021-06-23 17:37:49 +03:00
|
|
|
});
|
2021-06-02 11:36:22 +03:00
|
|
|
|
2021-06-23 17:37:49 +03:00
|
|
|
await updateChecker.check();
|
2021-05-27 16:53:55 +03:00
|
|
|
};
|
2021-06-23 14:01:43 +03:00
|
|
|
|
|
|
|
module.exports.scheduleRecurringJobs = () => {
|
|
|
|
// use a random seconds/minutes/hours value to avoid spikes to the update service API
|
|
|
|
const s = Math.floor(Math.random() * 60); // 0-59
|
|
|
|
const m = Math.floor(Math.random() * 60); // 0-59
|
|
|
|
const h = Math.floor(Math.random() * 24); // 0-23
|
|
|
|
|
|
|
|
jobsService.addJob({
|
|
|
|
at: `${s} ${m} ${h} * * *`, // Every day
|
|
|
|
job: require('path').resolve(__dirname, 'run-update-check.js'),
|
|
|
|
name: 'update-check'
|
|
|
|
});
|
|
|
|
};
|