no issue
Mixins are deprecated in Ember so we want to remove their usage. The `CurrentUserSettings` mixin was used in Route files to provide `transitionAuthor()` (that also transitions contributors) and `transitionEditor()` methods so the the consuming route could use them to prevent access to authors/editors. In practice the only reason this was used was to prevent access to admin-only routes.
- added an `AdminRoute` class that inherits from our `AuthenticatedRoute` class
- when any route inherits from this class it will only allow access to admins and owners, any other user will be redirected to the home screen (dashboard or site depending on permissions)
- updated all of our admin-only routes to use the new `AdminRoute`
- allowed for removal of `CurrentUserSettings` mixin usage
- allowed for `beforeModel()` hooks to be removed from consuming routes in many cases
- some admin-only routes were extending/inheriting directly from Ember's `Route` based on the assumption that the router hierarchy would have a parent route perform the redirect. Those have also been switched to `AdminRoute` for consistency and to prevent accidentally making them available if the router hierarchy changes
- `/#/settings` does not use the `AdminRoute` so that it can redirect to the current user's setting page for non-admin users
- removed `CurrentUserSettings` mixin file
- cleaned up unnecessary computed property and function used for redirect-when-disabled in the Zapier route
no issue
Having `session.user` return a promise made dealing with it in components difficult because you always had to remember it returned a promise rather than a model and had to handle the async behaviour. It also meant that you couldn't use any current user properties directly inside getters which made refactors to Glimmer/Octane idioms harder to reason about.
`session.user` was a cached computed property so it really made no sense for it to be a promise - it was loaded on first access and then always returned instantly but with a fulfilled promise rather than the underlying model.
Refactoring to a synchronous property that is loaded as part of the authentication flows (we load the current user to check that we're logged in - we may as well make use of that!) means one less thing to be aware of/remember and provides a nicer migration process to Glimmer components. As part of the refactor, the auth flows and pre-load of required data across other services was also simplified to make it easier to find and follow.
- refactored app setup and `session.user`
- added `session.populateUser()` that fetches a user model from the current user endpoint and sets it on `session.user`
- removed knowledge of app setup from the `cookie` authenticator and moved it into = `session.postAuthPreparation()`, this means we have the same post-authentication setup no matter which authenticator is used so we have more consistent behaviour in tests which don't use the `cookie` authenticator
- switched `session` service to native class syntax to get the expected `super()` behaviour
- updated `handleAuthentication()` so it populate's `session.user` and performs post-auth setup before transitioning (handles sign-in after app load)
- updated `application` route to remove duplicated knowledge of app preload behaviour that now lives in `session.postAuthPreparation()` (handles already-authed app load)
- removed out-of-date attempt at pre-loading data from setup controller as that's now handled automatically via `session.handleAuthentication`
- updated app code to not treat `session.user` as a promise
- predominant usage was router `beforeModel` hooks that transitioned users without valid permissions, this sets us up for an easier removal of the `current-user-settings` mixin in the future
no issue
We weren't correctly clearing state for the "display modal" booleans when leaving screens. This meant that it was possible to end up in a state where where every time you access a screen you get the unsaved changes modal
no issue
- moved `document-title` Route extension's functionality into the `ui` service
- updates the title each time the router service emits a route changed event
- `ui.updateDocumentTitle()` can now be called directly from components rather than the confusing `this.send('updateDocumentTitle')` bubbling behaviour
- refactored the `titleToken` implementation to use the now-formalised `RouteInfo`'s `metadata` field (https://github.com/emberjs/rfcs/blob/master/text/0398-RouteInfo-Metadata.md#appendix-a)
no issue
- removed `styleBody` mixin in favour of using Ember's `buildRouteInfoMetadata` hook and router events in the `ui` service
- refactored separate CSS classes for each unauthenticated route into a single `.unauthenticated-route` class because hiding mobile nav whilst unauthenticated was the only use for body classes
no issue
- ran [es5-getter-ember-codemod](https://github.com/rondale-sc/es5-getter-ember-codemod)
- [es5 getters RFC](https://github.com/emberjs/rfcs/blob/master/text/0281-es5-getters.md)
- updates the majority of `object.get('property')` with `object.property` with exceptions:
- `.get('nested.property')` - it's not possible to determine if this is relying on "safe" path chaining for when `nested` doesn't exist
- `.get('config.x')` and `.get('settings.x')` - both our `config` and `settings` services are proxy objects which do not support es5 getters
- this PR is not exhaustive, there are still a number of places where `.get('service.foo')` and similar could be replaced but it gets us a long way there in a quick and automated fashion
no issue
Automated tools, code generators, and editor integrations are increasingly standardising on the import style used in `ember-modules-codemod`. Our import style differed a little with regards to service/controller injection imports which meant we were starting to see inconsistent naming.
closesTryGhost/Ghost#8483
- Added a new modal component that gets rendered when leaving general/settings after changes have been done but not saved
- Removed independent saving logic for social URL for consistent UX
no issue
- add eslint-plugin-ember, configure no-old-shims rule
- run `eslint --fix` on `app`, `lib`, `mirage`, and `tests` to move imports to the new module imports
- further cleanup of Ember globals usage
- remove event-dispatcher initializer now that `canDispatchToEventManager` is deprecated
no issue
- adds `eslint-plugin-sort-imports-es6-autofix` dependency
- implements ESLint's base `sort-imports` rule but has a distinction in that `import {foo} from 'bar';` is considered `multiple` rather than `single`
- fixes ESLint's autofix behaviour so `eslint --fix` will actually fix the sort order
- updates all unordered import rules by using `eslint --fix`
With the increased number of `import` statements since Ember+ecosystem started moving towards es6 modules I've found it frustrating at times trying to search through randomly ordered import statements. Recently I've been sorting imports manually when I've added new code or touched old code so I thought I'd add an ESLint rule to codify it.
no issue
- adds `settings` service that acts as a proxy to the singular settings model with methods to fetch and reload, also prevents accidentally loading only some settings types which has caused problems in the past
- updates app boot, signin, and signup processes to fetch settings ensuring that any part of the app can grab settings synchronously if needed
- removes `timeZone` service, it's no longer needed as we can grab `settings.activeTimezone` directly
- replaces all store queries for the settings model with appropriate `settings` methods
- refactors `apps/*` routes/controllers, they had become a little convoluted with the way they were dealing with settings and the new service helped to clean that up
no issue
- updates `package.json` details to better reflect the separation from the `Ghost` package
- update ember config and all import statements to reflect the new `ghost-admin` module name in `package.json`
closes TryGhost/Ghost#6406
follow-up PR of #2
- adds a `timeZone` Service to provide the offset (=timezone reg. moment-timezone) of the users blog settings
- `gh-datetime-input` will read the offset of the timezone now and adjust the `publishedAt` date with it. This is the date which will be shown in the PSM 'Publish Date' field. When the user writes a new date/time, the offset is considered and will be deducted again before saving it to the model. This way, we always work with a UTC publish date except for this input field.
- gets `availableTimezones` from `configuration/timezones` API endpoint
- adds a `moment-utc` transform on all date attr (`createdAt`, `updatedAt`, `publishedAt`, `unsubscribedAt` and `lastLogin`) to only work with UTC times on serverside
- when switching the timezone in the select box, the user will be shown the local time of the selected timezone
- `createdAt`-property in `gh-user-invited` returns now `moment(createdAt).fromNow()` as `createdAt` is a moment date already
- added clock service to show actual time ticking below select box
- default timezone is '(GMT) Greenwich Mean Time : Dublin, Edinburgh, London'
- if no timezone is saved in the settings yet, the default value will be used
- shows the local time in 'Publish Date' in PSM by default, until user overwrites it
- adds dependency `moment-timezone 0.5.4` to `bower.json`
---------
**Tests:**
- sets except for clock service in test env
- adds fixtures to mirage
- adds `service.ajax` and `service:ghostPaths` to navigation-test.js
- adds unit test for `gh-format-timeago` helper
- updates acceptance test `general-setting`
- adds acceptance test for `editor`
- adds integration tests for `services/config` and `services/time-zone`
---------
**Todos:**
- [ ] Integration tests: ~~`services/config`~~, ~~`services/time-zone`~~, `components/gh-datetime-input`
- [x] Acceptance test: `editor`
- [ ] Unit tests: `utils/date-formatting`
- [ ] write issue for renaming date properties (e. g. `createdAt` to `createdAtUTC`) and translate those for server side with serializers
closes#6534
- new input fields in general settings incl. validation
- facebook and twitter as new models in settings.js
- adds values for facebook and twitter to default-settings.js
- adds blog helpers for facebook and twittter
- rather than saving the whole URL, the Twitter username incl. '@' will be extracted from URL and saved in the settings. The User will still input the full URL. After saving the blog setting, the stored Twitter username will be parsed again as the full URL and available in the input field. A custom transform is used for this.
- adding meta fields to be rendered in {{ghost_head}}:
- '<meta property="article:publisher" content="https://www.facebook.com/page" />' and
- '<meta name="twitter:site" content="@user"/>'
- adds facebook and twitter to unit test for structured data
- adds unit test for general settings
- adds acceptance test for new input fields in general settings
- adds a custom transform for twitter model to save only the username to the server
- adds unit test for transform
no issue
- review use of Ember core hooks and add a call to `this._super` if missing
- fix a few occurrences of using the wrong component lifecycle hooks that could result in multiple/duplicate event handlers being attached
`_super` should always be called when overriding Ember's base hooks so that core functionality or app functionality added through extensions, mixins or addons is not lost. This is important as it guards against issues arising from later refactorings or core changes.
As example of lost functionality, there were a number of routes that extended from `AuthenticatedRoute` but then overrode the `beforeModel` hook without calling `_super` which meant that the route was no longer treated as authenticated.
no issue
- add ember-suave dependency
- upgrade grunt-jscs dependency
- add a new .jscsrc for the client's tests directory that extends from client's base .jscsrc
- separate client tests in Gruntfile jscs task so they pick up the test's .jscsrc
- standardize es6 usage across client
refs #5614 and #5503
- update private blog type, including update to settings.edit
- switch order of populate settings & update fixtures + populate all settings
Private blog settings should not be returned by public endpoints
therefore they need a type which is not `blog` or `theme`.
`core` doesn't suit either, as those settings don't usually have UI
To resolve this, I created a new type `private` which can be used
for any setting which has a UI but should not be public data
No Issue
- Switch resources to routes.
- No longer nest "settings" routes so the router reflects
the way the templates are rendered.
- Remove renderTemplate override from settings routes.
- Remove unneeded routes, controllers, and views.
- Adjust users page so that infinite scroll loading of users works
and markup remains the same for Zelda styling.
fixes#5136
- wrap notification fetch with a user role check to remove console error
- move author transition down to local route for users/user so that there's no infinite loop
- replace all store calls to fetch the current user with the session user instead
