Now settings live in a dedicated space, the settings blueprint can be used by Pillar applications, and the templates can be extended or overridden. Moved subscription and email settings to the blender-cloud repository.
Setting flask_login.current_user ourselves was a bad idea, and messed up
flask_login's internal administration. Our code now just manages
g.current_user in these specific instances, which works fine.
- No more direct access to g.current_user, unless unavoidable.
- Using pillar.auth.current_user instead of g.current_user or
flask_login.current_user.
- p.a.current_user is never checked against None.
- p.a.current_user.is_authenticated or is_anonymous is used, and never
together with a negation (instead of 'not is_anon' use 'is_auth').
- No more accessing current_user a a dict.
- No more checks for admin role, use capability check instead.
Also added SERVER_NAME in config_testing and pre-populated the keys of OAUTH_CREDENTIALS, since the implementation of providers is part of the application.
This is an in-between change. In the future, we want to always set
g.current_user so that it's never None (but rather an AnonymousUser
instance). However, there is still some code that assumes that when
g.current_user is not None the user is logged in. This should be
addressed first.
When a new user is created, two things happen:
- before inserting into MongoDB, the organizational roles are given
- after inserting, the organizations are updated to move the user from
`unknown_members` to `members`.
This actually returns an AnonymousUser object, instead of None, when the
user is not logged in.
For compatibility with existing code, this function doesn't set
g.current_user to that AnonymousUser instance. We may decide to do this
later.
With a PATCH request you can now:
- assign users,
- remove a user,
- edit the name, description, and website fields.
Only the organization admin user can do this.
