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
refs https://github.com/TryGhost/Ghost/issues/10318
- API has been updated to still work with `default_locale` for backwards compatibility but it makes sense for the client to match the underlying settings keys
requires fdeb7daf40
- swapped to using settings model for storing custom views instead of user accessibility field
- added conditional that checks current user is an admin/owner when displaying the manage custom views button in the content filter (only admins/owners can edit settings model)
- passed `session.user` into the `<GhContentFilter>` component as an argument so that the conditional getter doesn't need to handle async user access
- fixed no-shadow linting error in settings service
no issue
- removed an old guard that was exiting early when `user.accessibility` was null which meant that the default views were never being inserted into the custom views list
no issue
- the `custom-views` and `navigation` services would trigger their observers immediately when `this.session.user` changed but that would occur before authentication had fully finished which was resulting in the `this.session.user` access triggering a request with no cookie/an old cookie set and causing a 403 error that interrupted the setup and authentication flows
no issue
- list custom post views in collapsable sidebar navigation
- default views: Draft, Scheduled, Published (except for contributors)
- record expanded/collapsed state of the navigation menus in user settings via new `navigation` service
- adds `customViews` service that manages custom views
- provides list of default views
- gives access to "active" custom view based on current route and query params
- manages loading/saving of custom views to user settings
- show "Add view" button in the content filter when the posts list has been filtered
- show "Edit view" button in the content filter when the posts list filter matches a saved view
Co-authored-by: Peter Zimon <peter.zimon@gmail.com>
