The `Default language` E2E test detected the browser language was not
automatically detected when user does not have any cookie, it was always
falling back on the defaut language (en).
This commit is the result of several squashed commits which were
complicated to disjoin.
This rewrites the base UI, and the mail management interfaces.
allow domain owner and admins to reset password for a mailbox
they manage. The request is sent to dimail, which responds with
a new randomly generated password. This new password is sent to
secondary email.
The `BrowsableAPIRenderer` generates a form to test POST/PUT/... actions
and fill the FK fields with unfiltered data. This issue has been spoted
on visio and fixed https://github.com/suitenumerique/meet/pull/508
We want to persist the session during development. Otherwise the session
is reset everytime the server is restart. This behavior make developing
bot a front and back feature a nigthmare, we spend our time login again
and again.
Shamelessly copy/pasted from @lunika 's work
suitenumerique/docs@007854a
In this commit, we stop creating /users and /allows in dimail
for our dbs to be in sync. People with stop impersonating users
in dimail and will create mailboxes using its own credentials.
Dimail-api is currently outside of renovate' scope, which resulted in us having
to check and update dimail's image manually or, if failing to, discovering new
behaviors by chance or by errors in production. This should fix it.
Bump the lib to the latest version:
- update the post_get_or_create_user method signature
- allow silent login for OIDC (will require frontend implementation)
The secondary email address is no longer required for all creation
processes and we should not force the user to provide and store an
insecure email address.
Override save is a better way to auto generate api_key if
it is not set.
Default with random secret generate a new migration each time we
run `make makemigrations`.
Create new model to allow access of some API
endpoints with API Key authentification.
Scopes will allow to define permission access on those
endpoints.
This provides the way to disable the admin user creation at each
deployment. In production we don't want to persist a generic admin user:
it should be created once, at first deployment then replaced by
nominative accounts.
The new DRF version (3.16.0) adds a check on unique together and needs
more fields to be loaded. To prevent an extra query, we select the owner
value in the DB query.
