Ghost/core/server/api/canary/schedules.js

78 lines
2.4 KiB
JavaScript
Raw Normal View History

const models = require('../../models');
const postSchedulingService = require('../../services/posts/post-scheduling-service')('canary');
module.exports = {
docName: 'schedules',
publish: {
headers: {},
options: [
'id',
'resource'
],
data: [
'force'
],
validation: {
options: {
id: {
required: true
},
resource: {
required: true,
values: ['posts', 'pages']
}
}
},
permissions: {
docName: 'posts'
},
async query(frame) {
const resourceType = frame.options.resource;
🐛 Fixed scheduled post emails pointing at /404/ for the "view online" link no issue When scheduling a post to publish+send the "view online" link was pointing at https://site.com/404/ rather than the published post's url. The problem occurred because the `/schedules/` endpoint wraps it's post read+edit calls in a transaction. Context: - when a post is published with with the "send email" option the email record is immediately generated and added to the API response, as part of the email record generation we render the email content including fetching the url for the "view online" link - urls for all resources are handled by our `url` service, that service updates it's internal cache based upon model events such as the "edited" event triggered when a post is published - if the posts API controller is given a transaction, the email record is also generated inside of that transaction however at this point the `url` service will not have been updated because the post record hasn't been committed meaning it has no available url for the post Fix: - removed the `models.Base.transaction()` wrapper around the post read+update in the `/schedules/` API controllers - we don't need a transaction here. It was added as protection against another write request coming in between the `/schedules/` controller reading a post and publishing a post but we already have protection against that in the form of collision detection - if a write request comes in and commits between the schedules controller reading the post and updating it, the scheduler's update call will fail with a collision error at which point the scheduler itself should retry the request which could then publish the post successfully if everything else is in order
2020-10-08 12:25:27 +03:00
const options = {
status: 'scheduled',
id: frame.options.id,
context: {
internal: true
}
};
const {scheduledResource, preScheduledResource} = await postSchedulingService.publish(resourceType, frame.options.id, frame.data.force, options);
const cacheInvalidate = postSchedulingService.handleCacheInvalidation(scheduledResource, preScheduledResource);
this.headers.cacheInvalidate = cacheInvalidate;
const response = {};
response[resourceType] = [scheduledResource];
return response;
}
},
getScheduled: {
// NOTE: this method is for internal use only by DefaultScheduler
// it is not exposed anywhere!
permissions: false,
validation: {
options: {
resource: {
required: true,
values: ['posts', 'pages']
}
}
},
query(frame) {
const resourceModel = 'Post';
const resourceType = (frame.options.resource === 'post') ? 'post' : 'page';
const cleanOptions = {};
cleanOptions.filter = `status:scheduled+type:${resourceType}`;
cleanOptions.columns = ['id', 'published_at', 'created_at', 'type'];
return models[resourceModel].findAll(cleanOptions)
.then((result) => {
let response = {};
response[resourceType] = result;
return response;
});
}
}
};