closes https://github.com/TryGhost/Team/issues/1647
- sending the embedded `email` record back to the API when saving could trigger "Request entity too large" errors for very large posts that were sent as email because it doubles up on the request size
- `post.email` is a read-only property and is ignored by the API so there's no point serializing it and making request bodies larger than they need to be
refs e021843e3f
- fixed closing of alerts due to missing `.args` after migrating to glimmer syntax
- updated related tests for glimmer component syntax
no issue
- migrated `notifications` service from EmberObject to true native class
- switched to tracked properties and use of `TrackedArray`
- swapped computed properties to getters
- dropped unnecessary usage of `get` and `set`
- migrated alert/notification related components to Glimmer components
no issue
- the relationship is no longer used (it was a temporary solution whilst we built full member events) and was never fully set up resulting in warning output in test runs
- dropped remaining vestiges of the relationship
no issue
`ember-cli-mirage` replaced the use of a default function export with a `createServer` function that applies config and deprecated the older mirage config export style. It will also soon drop support of the separate `testConfig` export we used for defining our test routes.
- switched to the newer `return createServer(config);` server configuration approach
- extracted dev and test routes into separate files for a cleaner base config
no issue
- the API response is now empty so returning the parsed response is null/undefined resulting in `<GhTaskButton>` showing a failure state
- switched to returning an enforced `true` value, if there was an error that's handled by the try/catch
refs https://github.com/TryGhost/Team/issues/1650
- Some places only checked for Stripe being connected via the 'connect' method and ignored the 'direct' method
- Updated (where possible) admin to use the new calculated `paid_members_enabled` setting
no issue
- if a markdown card is created and destroyed before the simplemde+codemirror instance is fully initialised we could throw errors due to simplemde calling methods on objects that don't yet exist during teardown
- we also had issues with the `_applyToolbarStyles()` method being called async by event handlers after the component was destroyed
no issue
- selecting a date in a future month always selected the same day number in the current month, if that was in the past it would also reset to "in 5 minutes"
- we were grabbing the day/month/year from the moment object provided by the calendar picker but we weren't using the correct property names, moment.js uses `months` and `years` instead of `month` and `year`
no issue
- fixed incorrect conversion of time when converting between site tz and utc when setting scheduled hour/minute in publish flow
- we initially created a UTC `newDate` moment from `publishOptions.scheduledAtUTC` but then used `newDate.tz(siteTimezone).format()` to get the time which was the source of the bug, it was assumed that was a non-destructive action returning a new date but it actually changed the underlying date resulting in the later calculations causing timezone adjustments to be applied twice
- simplified by not converting to UTC inside the publish-at component as that's already handled inside PublishOptions
- fixed time not resetting to minimum schedule time when set to earlier date than allowed
no issue
Problem:
- the server stores time with second-level precision but we send milliseconds
- when scheduling a post we were storing the selected publish-at time in the PublishOptions instance with non-zero milliseconds as the initial date was based on now+5mins
- when we were saving after the initial schedule that millisecond-containing time was still being used resulting in a perceived time difference in our client-side and server-side validations indicating that the published_at value should be updated, but when that time was <2 mins in the future the published_at change validation was triggered resulting in errors
Solution:
- ensure we only set times on PublishOptions with 0 milliseconds
- update client-side validations so we only trigger published_at validation when it's dirty
Also fixed:
- client-side validation errors were not shown on the confirm step due to a missing `.args`
