We need to make requests to the frontend URL, not the Admin API - but
the Admin X Framework doesn't currently support that, so instead we'll
use a simple `fetch` for now.
---------
Co-authored-by: Princi Vershwal <vershwal.princi@gmail.com>
- this change contains the removal of the `promise.allsettled` package,
as this is not needed on Node 12+, which removes 75 further dependencies
in production mode
ref ENG-1035
We didn't have a test assertion for when a user is prompted with a limit upgrade modal, which verifies that a click on the `Upgrade` button will redirect correctly to the Billing App (`\pro` route).
ref https://linear.app/tryghost/issue/ENG-1254
- we currently only store a cancellation reason when a member cancels
manually in Portal
- we now also store "Payment failed" when the cancellation is automatic
due to several payment failures
refs
[ENG-709](https://linear.app/tryghost/issue/ENG-709/%F0%9F%90%9B-bad-redirects-causing-container-tear-down)
Added validation to prevent RegEx's susceptible to ReDoS from being used
with custom redirects. Also moved error details out of `context` and
into `errorDetails` to be consistent with error logging elsewhere as
well as fix issue in admin-x where blank screen would be shown when an
error occurred during redirects upload (due to logic not accounting for
`context` being an object)
fixes https://linear.app/tryghost/issue/ENG-642
- When a subscription is in the `canceled` state the corresponding
Member has no access to the Ghost site. The only time a Member will
continue to have access if their subscription is due to cancel at the
period end is if it is still in an active state, which is one of
`active` `trialing` `unpaid` or `past_due`
- When a subscription is canceled immediately (i.e. before the end of
the current billing period), we now render "Ended" without a date,
because we don't store the cancellation date in the subscription object.
We previously used "Ended {current_period_end}" which would sometimes
lead to dates in the future
- Bonus: refactored code and added unit tests
---------
Co-authored-by: Sag <guptazy@gmail.com>
- the existing code creates a new moment instance, takes away some days
and then formats the result
- this is run for every entry of the member attribution stats, which
means dashboards for big sites with a lot of attribution data become
slow
- this value doesn't change across each iteration of the filter, so we
can just extract it out and calculate it once
- this commit removes this code block from the flamegraph completely
fix https://linear.app/tryghost/issue/ENG-779/%F0%9F%90%9B-cmds-does-not-save-member-profile-changes
- previously, pressing Cmd+S on a member profile would save the profile,
but the dirty attributes weren't being cleaned, so the application
would trigger the leave confirmation when exiting
- now, we've fixed the code to keep a dynamic scratch member,
- long term, we should get rid of the scratch model, but this still
allows us to fix the bug for now
closes https://linear.app/tryghost/issue/ENG-1255
- updated Koenig packages including:
- addition of `/preview` for public preview card
- fix for HTML import from Google Docs
- fix for embed thumbnails being cut off in email
- fix for wide image card width on medium screens
- multiple fixes for unhandled (but non user-visible) errors causing noise in console and error logging
ref https://linear.app/tryghost/issue/ONC-111
- changed posts fetching/display behavior to be client-side instead of server-side
- admin will issue (potentially multiple) requests based on the desired status(es)
- updated admin acceptance test for missing coverage
I've pulled the sort from the database query as this triple sort
performs very poorly at scale (taking ~4s+ past ~20k posts sometimes).
Instead, we now split up the fetch to grab only one status at a time and
use the front-end logic to handle displaying scheduled, then drafts,
then published. This should result in a much more responsive view.
We will separately change the default sort on the Admin API as that was the ultimate intent for this change.
- `faker` was the original dependency but the maintainer ended up
deleting the repo, so development continued in `@faker-js/faker`
- we're already using that dependency, so we can make a few simple
changes and remove the old dependency from our repo
DES-27
There are two patterns used in settings modals for action buttons:
1. [Cancel] and [Save & close] (sometimes it's [Cancel] and [OK],
inconsistently) — example: Staff details, Tier details, Navigation,
Recommendation
2. [Close] and [Save] — example: Design settings, Portal, Newsletter
details etc.
This is confusing and leaves people confused and uncertain about what's
going to happen in one or the other case.
