refs https://github.com/TryGhost/Team/issues/1666
- it seems like we may have a situation where `.activateTheme()` can be called simultaneously resulting in unexpected behaviour in the sync such as duplicate theme setting records
- adjusted behaviour to keep track of the currently running activation within the service and if `.activateTheme()` is called again whilst it's in progress it will wait for completion of the first sync before exiting early or continuing with a new activation
**Note:** There is a known edge-case if there are _more_ than 2 parallel `.activateTheme()` calls. We don't believe that will be an issue but calling it out in case we do still see duplicated custom setting records being created.
Co-authored-by: Kevin Ansfield <kevin@lookingsideways.co.uk>
no issue
- we were passing the theme name directly in the model query filter string without any surrounding `'` chars meaning we were generating invalid filters
no issue
Ghost allows multiple themes with the same `name` value in `package.json` so it assigns custom names based on the file name. When syncing we were only looking at the package.json `name` value so there could be a syncing clash when swapping between active themes.
- added `name` as the first argument to `.activateTheme(name, theme)` so that the service's consumer is in control of settings sync applying to it's known theme name
refs https://github.com/TryGhost/Team/issues/1104
- better matches the context of the request as we're validating known keys and valid options from multiple settings
- "404 Not Found" didn't make sense because `/custom_theme_settings/` _does_ exist, it's just that one setting key wasn't known
- "400 Bad Request" didn't make sense because the request was understood, it just failed validation of the setting values
refs https://github.com/TryGhost/Team/issues/1104
- there was a mismatch of template options when throwing error on invalid select value meaning we were erroring but with the wrong error type and message
- added missing `lodash` dependency in package.json
no issue
- the `.browse()` call to fetch themes was not structured to filter out themes correctly so it was fetching all theme settings rather than only settings related to the current theme
no issue
- `for .. of` loop contained a `return` rather than a `continue` so the whole function was being exited with an unexpected `undefined` return value after the first loop where an unknown setting is removed
refs https://github.com/TryGhost/Team/issues/1070
- receives settings array as provided by through Ghost's API
- errors if a provided setting key does not already exist in the database (settings are only created when syncing with a theme)
- errors if a provided select setting value does not match the theme-provided options
- providing there were no errors, updates each value in the database if it's changed along with the internal cache of full setting objects and the public key/value cache
- returns the same list of settings as `.listSettings()` for API consistency
refs https://github.com/TryGhost/Team/issues/1070
- return re-fetched settings after sync so they can be used in later activation steps
- added internal `activeThemeSettings` cache that stores full setting data along with saved values for use in API output
- added `listSettings()` that converts internal cache object into a settings array that matches API format
refs https://github.com/TryGhost/Team/issues/1070
- having a dependency on a model in the cache service meant that Ghost had to know about that and pre-initialize the cache during boot, even though that didn't actually do anything except create a cache instance
- by making the cache a simple key/value store able to be populated from the cache settings service when a theme is activated it means that Ghost doesn't need to perform any extra initialization when the cache is initialized via `require`
refs https://github.com/TryGhost/Team/issues/1070
- added `bread` util that acts as a wrapper for the provided model, if we have any business functionality needed when settings are added/removed then it will go here
- added primary "server" service that handles syncing of custom theme data extracted from a theme with the settings that are in the database and exported as "Service". Syncing rules on theme activation:
- if a new setting is seen, create it with the default value
- if a setting has it's type changed, remove it and create a new setting with the default value
- if a select setting's value is not a valid option, reset it to the default value
- added shared "frontend/server" service that exposes an in-memory cache of key/value pairs for the currently active theme
