refs https://github.com/TryGhost/Team/issues/1053
This table is going to be completely deleted at some point in the
future. It serves as a persistent datastore for a spike into collection
analytic events for members. We've opted for a generic table, rather
than a table for each event, so that we can push the DB to the limit in
terms of the length of the table, and find out performance issues A$AP
- as per 5a5a5d162e, the Bookshelf registry plugin is now in core
- we no longer need to explicitly load the plugin, and it displays a
warning if you do
- this change also turns `._models` into `.registry.models`, so our code has
been updated to reflect that
- as per https://github.com/bookshelf/bookshelf/wiki/Migrating-from-0.15.1-to-1.0.0#default-to-require-true-on-modelfetch-and-collectionfetchone, models will now default to `{require:true}` during a fetch, which changes how Bookshelf will respond when a models yields no results
- instead of passing a `null` result, it will reject with an error, so we'd need to switch to `.catch`ing everything
- our code is set up to handle all these null results and switching style is not currently on the cards so we want to use the existing behaviour for now
- to enable this, the `requireFetch` option needs to be added to the model definitions
refs https://github.com/TryGhost/Team/issues/947
- During the work of the UI and moving `email_only` flag to publish menu it created the situation where the publishing of the post was at the same time as adding `email_only` flag, resulted in not picking up teh `sent` status as the `posts_meta` model and record were's available during save.
- Adding the incoming attribute check for email_only flag covers this situation
no-issue
Writing code outside of Ghost which deals with the models is currently
done by passing the models which are needed to the external module,
rather than the instance of ghostBookshelf. This does not give us a way
to create transaction to run queries in. This method is designed as a
simple way to give all models the power to create a transaction for
themselves.
This will be used in @tryghost/members-api for example to ensure that
failures in communication with the Stripe API will rollback the related
inserts in the database.
refs https://github.com/TryGhost/Team/issues/873
We need a relation between members and their product events so that we
can pull out the events for a particular member to generate the start
date of their comped access to a product.
refs https://github.com/TryGhost/Team/issues/946
In order to bulk remove relations between members and labels we need a
way to get hold of all of the existing relations between a label and a
set of members.
refs https://github.com/TryGhost/Team/issues/714
In order to order products by their monthly price we need to apply a
join with the stripe_prices table when querying so we have access to the
amount column of stripe_prices.
As this ordering is core to how the tiers feature is intended to work,
we have added it as the default order. But this can be overriden by
manually passing the order option.
Also ensured that we do not create duplicate products in test fixtures
refs https://github.com/TryGhost/Team/issues/946
This refactor pulls out the core logic so that we can easily add other
bulk operations without having to duplicate even more logic.
It also gives a consistent return value between bulk operations, renaming
`unsuccessfulIds` and `unsuccessfulRecords` to `unsuccessfulData`
We also add a bulkEdit method which will be used to bulk unsubscribe members
from the newsletter.
refs https://github.com/TryGhost/Team/issues/953
- We need to track email-only posts that have been sent out. New status was chosen as a way to differenciate such posts.
- Introducing a new "email post" type, conceptually like "page", was considered. Because there is no clear roadmap for "email post" becoming a bigger part of the product yet and a lot of uncertainty around this concept, overhead needed to introduce a new type was just too much to do at this moment. It's still a possibility in the future
refs https://github.com/TryGhost/Team/issues/949
- When post is marked as "email-only" we can send it out to the selected audience when publishing without making the post publicly available
- The feature is available for experimentation behind "email only" alpha flag available in labs
refs https://github.com/TryGhost/Team/issues/949
- It's relly hard to grasp what's going on in ifs with multiple conditions that are written down in a signle, gazzilion-line format. Having a nice column as way more readable
refs https://github.com/TryGhost/framework/pull/19
The @tryghost/bookshelf-filter plugin no longer bundles hardcoded
relations and expansion definitions, instead leaving it up to the
library consumer to implement.
This PR adds the preexisting relations and expansions to the relevant
models, in order to preserve our existing filtering functionality.
closes https://github.com/TryGhost/Team/issues/743
Unlike tags, a label has a unique constraint on its `name`. So saving a new label on member with the same name as existing label fails with error due to unique constraint error.
- adds id for new label to match existing label if they are the same name, which avoids creating a new label
refs https://github.com/TryGhost/Team/issues/880
The aggregate for `paid_delta` was incorrect as it did not handle the
case where an event went from paid->comped or from comped->paid. This
resulted in an overcount for paid members.
- This isn't really a "service" - it's a set of utilities for working with labs flags
- It's also required all over the place, and doesn't require anything that isn't shared
- Therefore, it should live in shared
- This isn't really a "service" - it's a set of utilities for working with labs flags
- It's also required all over the place, and doesn't require anything that isn't shared
- Therefore, it should live in shared
- This is a precursor to trying to split apart into:
- model events + webhooks system which makes sense
- frontend events which should be independent or removed
- maybe some concept of a settings manager that we can use in various places to bind logic 🤔
- other usages of events that should be refactored to not use events
refs 8a1fd1f57f
refs 5584430ddc
- The change to async/await in the original commit 558443 was causing problems in downstream dependencies (create-error package) where it was loosing a context of "this". It's not a direct dependency so I didn't go yak shaving into where exacly the context is lost.
- The fix to keep a correct context of "this" was sticking to an existing pattern using regular function returning promises. Once we need to redo them into async/await we can investigate if there's a way around create-error's context prolbem
closes https://github.com/TryGhost/Team/issues/817
refs 6d083ee00e/packages/bookshelf-pagination/lib/bookshelf-pagination.js (L256)
- The 500 error is not the best we can do in this situation and throwing a 400 just like we doo in a referenced commit would keep the convention
- The underlying problem of the bug is bigger - we allow the fields named the same way as relations to leak into the db query and that causes an incorrect SQL syntax. It's a bigger problem which would need a separate, holistic approach
- This is part of the quest to separate the frontend and server & get rid of all the places where there are cross-requires
- At the moment the settings cache is one big shared cache used by the frontend and server liberally
- This change doesn't really solve the fundamental problems, as we still depend on events, and requires from inside frontend
- However it allows us to control the misuse slightly better by getting rid of restricted requires and turning on that eslint ruleset
refs https://github.com/TryGhost/Team/issues/806
This relation sets up the ability to both read and write relations via
the Product model, allowing us to expose benefits via the Admin Product
API.
refs https://github.com/TryGhost/Team/issues/806
This is the model to represent the Benefit resource stored in the
`benefits` table. The `onSaving` method has been copied from the Tag
model and ensures that we have a unique slug.
refs 188de00489
- this fix was incorrect - the function should have been on the
prototype but I'd moved it over incorrectly into the static class functions
- this commit moves `defaultColumnsToFetch` to the prototype functions
and reverts the referenced commit back to `this.prototype` as expected
- this wasn't including the custom columns from the `post` model, which
was causing tests to fail
- pro tip: run tests!
refs a457631a20
- `defaultColumnsToFetch` was moved to the CRUD plugin in the referenced
commit, which makes it a function on `this` instead of `this.prototype`
- this means the function doesn't exist and Admin throws an error when
you start typing in the search bar because the API 500s
- this commit switches it to `this.defaultColumnsToFetch()`
refs https://github.com/TryGhost/Team/issues/808
- see referenced issue for context, but turning this function into
async-await seems to have broken error handling when deleting things
that don't exist
- i'm really not sure why - but my running theory is that it's something
to do with Bluebird Promises vs native Promises
- this should keep the same functionality until I can investigate what
is going on
issue https://github.com/TryGhost/Team/issues/750
- Only accessible by admins
- Resets all staff users' passwords and prevents them to log-in
- Sends them a reset email password to give them back access to their account
- Closes all existing staff user sessions
no issue
- `setId` is only used within the `events` plugin and it makes sense to
keep code together
- we don't lose anything by putting it here, but it should make it
easier to test in the future
no issue
- `formatOnWrite` doesn't override anything in Bookshelf but we use it
within the `override` plugin and sub-models may override it, so it's
easier to keep these things together
no issue
- we were only importing the `db` to access the `knex` instance, but
we can get this through the Bookshelf instance
- switches to pulling out `knex` from Bookshelf so we can remove the
remaining local require
no issue
- this commit extracts code relating to bulk DB operations into a
separate plugin
- it __could__ go into the CRUD one but these operations are a little
more involved
