0
Fork 0
mirror of https://github.com/TryGhost/Ghost.git synced 2025-02-10 23:36:14 -05:00
ghost/test/unit/data/schema/integrity_spec.js
Kevin Ansfield 1dfaf8c5f8
Added migration to store from/reply-to values in email table (#12204)
no issue

The email table should be a reference for all data that was used when sending an email. From and Reply-to addresses can change over time and we don't have any other reference for their value at the time of sending an email so we should store them alongside the email content.

- schema updated with `from` and `reply_to` columns
- both are set to `nullable` because we don't have historic data (can be populated and changed in later migrations if needed)
- neither `from` or `reply_to` have `isEmail` validations because they can have name+email in an email-specific format
- will help keep concerns separated in the future. `mega` service can deal with all of the email contents/properties, and the `bulk-email` service's concerns are then only email sending and any provider-specific needs
2020-09-24 08:20:10 +01:00

69 lines
3.1 KiB
JavaScript

const should = require('should');
const _ = require('lodash');
const yaml = require('js-yaml');
const crypto = require('crypto');
const fs = require('fs-extra');
const path = require('path');
const {config} = require('../../../utils/configUtils');
const schema = require('../../../../core/server/data/schema');
const fixtures = require('../../../../core/server/data/schema/fixtures');
const frontendSettings = require('../../../../core/frontend/services/settings');
const validateFrontendSettings = require('../../../../core/frontend/services/settings/validate');
const defaultSettings = require('../../../../core/server/data/schema/default-settings');
/**
* @NOTE
*
* If this test fails for you, you have modified one of:
* - the database schema
* - fixtures
* - default settings
* - routes.yaml
*
* When you make a change, please test that:
*
* 1. A new blog get's installed and the database looks correct and complete.
* 2. A blog get's updated from a lower Ghost version and the database looks correct and complete.
*
* Typical cases:
* You have to add a migration script if you've added/modified permissions.
* You have to add a migration script if you've add a new table.
* You have to add a migration script if you've added new settings to populate group/flags column.
*/
describe('DB version integrity', function () {
// Only these variables should need updating
const currentSchemaHash = 'edd2611c5a774ac64035b71ea966ade4';
const currentFixturesHash = '29148c40dfaf4f828c5fca95666f6545';
const currentSettingsHash = 'c8daa2c9632bb75f9d60655de09ae3bd';
const currentRoutesHash = '3d180d52c663d173a6be791ef411ed01';
// If this test is failing, then it is likely a change has been made that requires a DB version bump,
// and the values above will need updating as confirmation
it('should not change without fixing this test', function () {
const routesPath = path.join(config.get('paths').defaultSettings, 'default-routes.yaml');
const defaultRoutes = validateFrontendSettings(yaml.safeLoad(fs.readFileSync(routesPath, 'utf-8')));
const tablesNoValidation = _.cloneDeep(schema.tables);
let schemaHash;
let fixturesHash;
let settingsHash;
let routesHash;
_.each(tablesNoValidation, function (table) {
return _.each(table, function (column, name) {
table[name] = _.omit(column, 'validations');
});
});
schemaHash = crypto.createHash('md5').update(JSON.stringify(tablesNoValidation), 'binary').digest('hex');
fixturesHash = crypto.createHash('md5').update(JSON.stringify(fixtures), 'binary').digest('hex');
settingsHash = crypto.createHash('md5').update(JSON.stringify(defaultSettings), 'binary').digest('hex');
routesHash = crypto.createHash('md5').update(JSON.stringify(defaultRoutes), 'binary').digest('hex');
schemaHash.should.eql(currentSchemaHash);
fixturesHash.should.eql(currentFixturesHash);
settingsHash.should.eql(currentSettingsHash);
routesHash.should.eql(currentRoutesHash);
routesHash.should.eql(frontendSettings.getDefaulHash('routes'));
});
});