- This is super specific code relating only to validating passwords.
- It's needed as a shared validator as we use other funnels to help people setup Ghost on Pro, but currently it's hard-baked into Ghost
- It's also not the greatest code. It'd be nice to be able to rework it and know that would automatically update everywhere passwords are set
- This is a really specific piece of code related to validating models against our internal schema.js format
- This doesn't make sense without a schema.js file
- It does depend on the internal validator and validate tools - but those are used elsewhere too, and can reasonably be moved out of the codebase
- I don't see schema.js moving out of the codebase any time soon. We can move the validator but it would be a class that requires schema via DI
- For now my focus is on getting the data/validation tooling separated and making clear sense
- Improving data/schema can come later :)
no issue
- `options` is not a correct type, so changed it to `Object` - maybe we
could introduce an `options` type at some point
- also fixed another case of incorrect subtype extraction from
`bookshelf`
no refs
- adding/changing products needs cache invalidation header otherwise frontend endpoints like `/members/api/site` use cached product data
- adds cache invalidation for both add and edit endpoints for products
refs d783a8d2d4
- we're removing i18n from Ghost core because it no longer meets our
needs
- this switches out i18n in the base Bookshelf model for our
`tryghost/tpl` package with a `messages` object of strings sprinkled
through the code
no issue
- eager-load: turned param import into typedef for reusability and fixed
attribute typing
- pagination:
- removed typing on helper function object - this was incorrect and
tsserver can pick up the real types a lot better, so removing it
reduces maintenance overhead
- `fetchPage` actually returns a Promise, so this fixes the typing
on the docs
- The data/validation module is made up of several loosely related things with lots of dependencies
- Separating out the various components makes it possible to see what's what, and importantly what has complex dependencies
- validator + validate probably go togetheri in an external module, the other two files should probably have their own homes in related areas of ghost e.g. schema -> data/schema/validate.js
no issue
Part of the effort to split ghost into smaller, decoupled parts. The
@root-utils package lets us avoid hard-coding a path to package.json,
and means that the ghost-version.js file could eventually be moved
into a separate module.
no issue
- the `Bookshelf` type wasn't being imported anywhere and editors were
showing warnings for the missing type
- also fixes use of `Bookshelf.Model` - this doesn't work if we declare
`Bookshelf` using a `@typedef` and the preferred syntax is using an
array index
- note: it still complains because we're calling functions that are only
declared in our custom Bookshelf Model but this is a step in the right
direction
no issue
- i18n is eventually going away in Ghost so we want to remove uses of it
- Bookshelf plugins are also getting extraced out of Ghost so we need to
remove all local requires
- i18n is being replaced by inline templating with strings stored in the
`messages` object
- this commit switches out the use of i18n in the Bookshelf plugins and
replaces the templating function with our `@tryghost/tpl` package
refs https://github.com/TryGhost/Team/issues/767
- adds new multiple products UI in Portal (works behind the `multipleProducts` feature flag)
- Portal's current single product UI behaves the same when flag is switched off
refs https://github.com/TryGhost/Team/issues/770
We want post feature image functionality to better match what's available inside the editor, to do that we'll need somewhere to store alt and caption meta data. `posts_meta` chosen because even though we want to make this generic for other tables in the future those tables also have a `feature_image` (or closely related) field.
- updated schema with new columns
- added migration to create columns
- cleaned new columns from API output
- not output on v2/v3
- conditionally output on v4/canary output based on labs flag
- bumped `@tryghost/admin-api-schema` to allow new columns through in canary API requests
- silently clean properties from input when labs flag is disabled
- updated acceptance tests so they fail if `admin-api-schema` is not letting the new fields through
no issue
`post.clean()` implementation was expecting a flat structure representing final API output but was being called before the flatten operation for `posts_meta` meaning the structure looked like `attrs.posts_meta.property` instead
- adjusted order in output serializers to call `clean()` after flattening the `posts_meta` object
- in `v2` output serializer, moved removal of properties from the serializer into `clean()` for consistency
no issue
Shows impact of new code behind labs flags through the existing acceptance/regression tests. Allows for existing tests to be updated to match new behaviour rather than requiring separate tests where individual flags are enabled. Should result in minimal test updating once code reaches GA.
- adds a forced `'labs:enabled'` fixture op that edits the `labs` setting to enable all flags then restarts the settings service to pick up the new setting
- modifies labs service to not remove ALPHA_FEATURE labs settings when running in a testing environment
- The underlying package-json package has had i18n ripped out using the new tpl utility instead
- It's also then been refactored to not be a class that needs instantiating
- This means it can be required directly and its public interface methods used where needed
- This is a much nicer, neater pattern for what is a mature utility library :)
- Traditionally all of Ghost's public-facing text was written in British English
- We're changing that to US English because that's more common
- US English should also be used in code e.g. properties are called color not colour
- most of these changes are in comments, but I've changed them so that we have US English in front of us always
- fixed a few other typos I noticed whilst there
refs https://github.com/TryGhost/Team/issues/772
- When the feature is introduced into Ghost at it's first lifecycle stage - "alpha" the rule is to have a "enableDeveloperExperiments" flag along with labs toggle turned on before it's usagble in the codebase
- The changeset introduced a "ALPHA_KEYS" concept which should allow distinguishing alpha flags from beta flags.
- We are going to get rid of the internal i18n tool because it doesn't solve a real use case
- Instead, we have a new tpl utility that does basic string interpolation
- This pattern will make it easier for us to decouple the codebase, and the new tool helps to keep the refactor surface area really small
- This is the first example of using the new tpl helper, so it also adds @tryghost/tpl
refs e17f5004cc
In case of Stripe disconnect, it was possible that the product table still contained reference to monthly/yearly price id while the price itself isn't present in the DB. As part of Stripe disconnect reset, this also resets monthly/yearly price id for product.
closes https://github.com/TryGhost/Team/issues/724
closes https://github.com/TryGhost/Team/issues/739
Currently, site owners are allowed to disconnect Stripe if they don't have any active subscriptions for a member. On disconnect, all stripe related data for the old account in DB should be cleared as using Stripe id for old account can cause weird failures due to incorrect Stripe key being used. This was also causing site owners to not be able to create new prices after connecting to new account as it ended up using old stripe product id which failed on Stripe request.
no refs
In case of Stripe disconnect, its possible that the product table still contains reference to monthly/price id while the object itself isn't present in the DB. In this scenario the stripe price returned is empty object instead of `null` , which then passes down empty object in the API that causes clients to fail if they just check existence of stripe price. The fix returns `null` value for monthly/yearly price in case it has no reference and is empty object.
no refs
Monthly/yearly price values on a product can be `null` when stripe is not connected, this change handles the prices passed to Portal settings to ignore null prices in the array.
closes https://github.com/TryGhost/Team/issues/761
With multiple products, each product can have an active monthly/yearly price, so we no longer store the monthly/yearly price ids in global settings but instead store them in product table directly. This means we need to update our global `@price` helper to also use the updated schema and use the monthly/yearly prices from product table instead of settings data.
no-issue
The default include values are empty arrays which are not falsy, so the
boolean OR operator would never use the second operand. Instead we
concatenate the options together so that the API can use all of them.
no-issue
The Frame object colocates the query, params & options data under a
single options property, this is not the case for the "original" data
however, which means that we need to explicitly check individual
"original" properties. We do not expect the `include` option to be used
as a param so that has been left out for now.
This reverts commit ea9a83d444.
refs https://github.com/TryGhost/Team/issues/755
- the default value for `show_header_icon` is `true` but if there's no publication icon set then it should be read as `false` when rendering the email
refs: https://github.com/TryGhost/Team/issues/759
- wired up a matchHelper feature flag & used the labsEnabledHelper tool to gate the helper
- added a first version of the match helper, which is intended to replace the has helper
- this is an experimental helper and may or may not make it to GA
- match is a simple comparison helper, right now it does a very basic equals or not equals comparison
- much more functionality is needed to reach parity with has
refs https://github.com/TryGhost/Team/issues/757
- The "type" value in settings is meant to be representing the data type stored in the "value" field. It was an overlooked bug in v4 API adding a mapper to group->type
refs https://github.com/TryGhost/Team/issues/755
Make use of the new settings in the email template when `enableDeveloperExperiments` flag is enabled.
- added header image output if set
- hide all header output if both show publication title+icon are disabled
- hide individual header output for title and logo based on individual settings
- add left-align and serif classes to title based on individual settings
- hide feature image when disabled
refs https://github.com/TryGhost/Team/issues/757
- There is no usecase for editing "labs" settings outside of canary/v4 API versions. Removing support for older versions makes the supported API surface smaller (easy maintenance).
refs https://github.com/TryGhost/Team/issues/757
- To safeguard from mise of a very permissing "object" value of the "labs" setting this change introduces an "allowlist" approach to filtering unrecognized labs flags
- Should allow maintainers to have a clear view of which labs flags are currently in use and manage them accordingly
refs https://github.com/TryGhost/Team/issues/757
refs https://github.com/TryGhost/Team/issues/332
refs ea6d656457
- We have a need a quick way to add features behind flags. The old way of "labs" is the quickest way to achieve this. It has ready tooling around it and well understood pitfalls. This change reintroduces "labs" group & key in settings table in the same shape it used to be (see reffed commit)
- Next step will be introducing very basic guard rails to protect from pitfalls previous implementation of "labs" had. This will include an allowlist based input validation for lab's object's data
- The labs being an "object" type is an EXCEPTION. Even though it's an antipattern we aim to move away from, for now it's the lowest impact solution that will unblock the use of flags in the system. A proper solution will come at some point.
