refs: https://github.com/Ghost/Ghost/commit/b5ee17b25
- When moving the site tests into e2e-api they broke because they were getting the changed settings value from the settings test
- The solution is to ensure the settingsCache is reset between tests, which is what this commit does
- This commit also renames the shutdown method to reset, because this is not a permanent operation
- It also renames the resetDb method to resetData, because the concept is we want the internal data to be reset, not just the DB
no-issue
The way we choose which email to send is too tightly coupled with the
magic link generation, which meant that when we added the new paid
signup email, the magic link looked like <url>?action=signup-paid rather
than <url>?action=signup - our welcome page logic was working off of
only using welcome pages for action=signup and so this broke.
- When starting ghost for e2e tests we create a content folder in the os tmp dir
- This means that the folder can change between suites as ghost is started and restarted
- For the most part this is fine, but theme storage caches the path to config (which makes sense, it's not meant to change whilst Ghost is in-memory)
- This is a quick-n-dirty fix that just makes it possible to update that path in the tests, so we know it's in sync
- Ideally we'd not cache the path, use a function to fetch it etc, or fully reset the theme storage layer, but this is the fix I have working today
and so it's going in to unblock things for now
refs https://github.com/TryGhost/Team/issues/1071
We switched to using tiers pivot table that stores list of tiers with access to post when visibility is set to `tiers`. For themes using v3 API while having posts restricted to specific tiers visibility, the post data will not include the list of tiers, which caused an unexpected error while trying to determine post access from tiers list. This change blocks access to post if specific tiers visibility is enabled without data available for list of tiers on post.
refs daeb06e835
- This is an additive change, and the parameter is optional so it's better to ship it right away (testing was hard as it's a chicken and an egg problem to have a feature flag in the setup route).
refs https://github.com/TryGhost/Team/issues/1321
- when updating the Email record after submitting all email batches we have a `catch` call but it was only logging the error
- added a call to Sentry so there's more visibility if those saves fail
refs https://github.com/TryGhost/Toolbox/issues/202
- this code suffers from two problems:
- when we don't have any new settings to insert, we still end up
fetching the columnInfo and owner info, even though we only need
them if we're inserting data. This results in 3 extra queries upon
boot
- secondly, we insert every setting with a separate query - MySQL and
SQLite both support batch inserts and knex has a utility to help us
that I've [used
before](38821c5242).
With 95 settings at the time of writing, this adds 94 extra queries
during the DB init
- this commit refactors the code so that we only fetch the columnInfo and
owner data if we've got new settings to insert, and batches the
inserts using knex's batchInsert util
- this query results in ~95 less queries during DB init and saves a
couple of queries during boot
loses TryGhost#13971
This fixes an issue with links containing # anchor. It makes sure the # part is at the end of the url like url?v=hash#anhor
Co-authored-by: Hannah Wolfe <github.erisds@gmail.com>
no issue
- the new eslint bump seems to flag this line up for using camelcase
- i'm not sure why this hasn't flagged before but it seems we want to
keep the naming because the function name has the same linting exemption
refs https://github.com/TryGhost/Team/issues/1296
- The `theme` must be a github `org/repo` string
- This uses the internal API instead of the services because the API has extra implementation details not present in the services.
refs https://github.com/TryGhost/Team/issues/1071
Default visibility for a post when set to specific tiers needs special handling as data for specific tiers is stored as an array of tiers on a pivot table. This change handles the default visibility for a new post when set to specific tiers to generate the right default values in model.
closes https://github.com/TryGhost/Team/issues/1311
For some sites, the `portal_products` array was created without any value and due to a possible bug in older version of Ghost, it also didn't get filled on Stripe connect with default product. This causes a side-effect of sites not showing the prices in Portal when tiers beta is enabled or is out as GA. This change populates the missing product data in `portal_product` for sites that have a single tier (haven't enabled tiers beta), as they right now don't have an option to hide the tier.
refs https://github.com/TryGhost/Team/issues/1071
Default content visiblity for specific tiers is now stored split between `default_content_visiblity` and `default_content_visibility_tiers` setting, with former storing the value as `tiers` and the latter stores the list of tiers that the visibility is restricted to. This migration transforms all existing sites that have default visibility stored as an NQL string from previous versions to follow the new model and store correctly on the new setting.
refs https://github.com/TryGhost/Team/issues/1071
Default content visibility for a post can be one of `public|members|paid|tiers`, where `tiers` denotes visibility restricted to specific tiers. This change adds a new setting to store the tier ids when default content visibility is set to `tiers`. This closely matches how the visibility is stored on `posts` table as well, with `visibility` stored as `tiers` and tiers data is stored on tiers pivot table.
refs https://github.com/TryGhost/Team/issues/1287
Currently we have a hard limit of how large an email filter can be,
which is very restrictive once a site starts using Tiers - by moving
toward a TEXT column, we essentially give the filters unlimited size.
This currently doesn't handle SQLite as there are no limits on VARCHARS
in SQLite.
The down migration is a loop so we don't have to handle values larger than
50 characters
no issue
- we check the presence of `members_free_signup_redirect` here but the
log line said `members_paid_signup_redirect`
- this must have been missed in review but it's simple enough to fix
refs https://github.com/TryGhost/Team/issues/1228
- We were displaying a message referencing paid subscriptions to all users, which was causing confusion
- We don't have the `member.paid` flag in this context, so we use the match helper on member.status not free
no issue
- `this` isn't referring to the correct `this` in this scope, and the
library is an import of the file anyway, so this fixes the undefined
function call as a result
fixes: https://github.com/TryGhost/Ghost/issues/12871
- This Ghost recommended email scanner, mail-tester.com, reports not having this alt as having an impact of -0.5 out of 10 on your email score.
refs https://github.com/TryGhost/Team/issues/1168
This migrates the existing settings onto the Tier objects, so that users
with Tiers enabled can seamless move from global settings to Tier level
settings - without losing/modifying data/functionality.
refs https://github.com/TryGhost/Team/issues/1071
- `products` relation is needed on post/page to tackle custom tiers visibility, this change attaches `products` as default include for frontend controllers
refs https://github.com/TryGhost/Team/issues/1071
Going forward, if the visibility of a page/post is set for specific tiers, we send a `tiers` array in API response that contains list of tiers with access. This change -
- updates post/page mapper to transform existing data where `visibility` is a custom nql string to tiers array
- updates default include for post/pages to include `products`, which allows attaching relevant tiers from the pivot table
- cleans up usage of `visibility_filter` in serialization
refs https://github.com/TryGhost/Team/issues/1071
We used `posts.visibility` originally to store visibility as `free|paid` with a character limit of 50. This same field was repurposed to store an NQL filter when member tiers is enabled. The NQL filter uses the slug of the tier name, which can easily create a filter longer than 50 characters, adding an unwanted limitation on number of tiers that can be added to post's visibility.
Going forward, we'd like to store the visibility of posts for tiers in a separate pivot table and instead store the value of `visibility` as `tiers` when restricting post access to specific tiers. This change -
- adds a new pivot table fixture for storing relation between posts and tiers
- adds a migration for creating the new table
- updates tests
