refs https://github.com/TryGhost/Team/issues/1166
Since we removed the creation of coupons from the Offers module, we must
emit events so that the Payments module can handle creating Coupons when
Offers are created.
We also export the events from the module so that they can be listened
to by the Payments module.
We also export other internals of the module so that the types can be
used.
refs https://github.com/TryGhost/Team/issues/1166
This will be handled by a payments module instead. In order to
disconnect Stripe we must delete all Stripe related data, which means an
Offer doesn't inherently have a stripe coupon id. Instead we can use a
payments service which will get/create the coupon for us when we need
it.
no-issue
Because we were checking for truthyness rather than existence when
updating properties on an Offer - it was impossible to set the
description to a blank string, as this is falsy.
refs https://github.com/TryGhost/Members/commit/5172e40646
When we updated to use the OffersAPI instead of OfferRepository this was
missed, and we were passing blank coupon to Stripe Checkout. This should
eventually be replaced with a call like `getCoupon(offerId)` from a
payments service.
refs https://github.com/TryGhost/Team/issues/1131
This adds a mapping between the status property used in the domain & API
and the active column used in the database. As we only have the usecase
of filtering by `status` right now, we have not added support for all
the other columns. Instead of these potentially erroring where the
column name does not match the property name in the domain/api - we've
added a transformer which will ignore all filters for properties other
than `status`. This follows postels law, in that we can be liberal with
the filters we accept, but conservative in the ones we implement.
refs https://github.com/TryGhost/Team/issues/1131
- Includes `status` on OfferDTO so client can use it
- Allows editing `status` of Offers
- Allows setting initial `status` when creating Offers
no-issue
This simplifies the handling of updating redirects for a code, and
doesn't affect our application layer because we never have the need to
change a code twice.
In future this should be replaced with events at the domain level - so
that we do not have to track changed properties and instead a redirect
service can listen to events, which would be dispatched on a successful
save by the repository.
