We introduce the Organization model has a "hat" for all
users and team.
Each User must have a "default" organization.
Each Team must have an organization.
When a User creates a new Team, the team is linked to their
default Organization.
For now the Organization should not be visible to end users
this is a purely technical aspect as it.
The models are also adding a permission to allow User to edit
an Organization, but for now there are no endpoints for that.
Next steps:
- Add an Organization to each User and Team on all environments
to mark Organization as mandatory in database.
- Add scope to Organization to list the Service Provider list
allowed for a User in an Organization.
- Add endpoints + frontend to manage Organization's scopes
In order to be in agreement with the back, we must modify the front
so as to no longer have infinite scroll in the team part.
It is also necessary to modify the tests accordingly
Disable retries and save trace for failed tests.
💚(ci) preserve server logs
Save server logs to the same place as Playwright reports to aid debugging.
💚(ci) move back to 1 worker on CI
At least three reasons
- seems redundant with sharding
- strong suspicion it's the reason for the ValidationError issue
- that way the comment no longer tells a lie ;)
💚(ci) improve E2E tests
Log into CHANGELOG to ensure the new test results impact PR status 🤷💚(ci) make dummy data creation more robust
This is a QR (Quick Response) fix for the failures in the "Add dummy
data" step in E2E testing. Proper QC (Quality Control) needs a bit
more thought.
The `DockerflowMiddleware` job is to add logs, sadly the
Sentry LoggingIntegration also catch these logs (at
level WARNING and above) which results in an extra alert
for the same purpose (the exception + the logger.error).
see https://github.com/mozilla-services/Dockerflow/blob/main/docs/mozlog.md
The fix is to ask Sentry to ignore this specific loggger
(`request.summary`).
Currently, it is complicated to understand the navigation between mailbox
management and role management for an email domain.
This is why we add tabs with explicit naming
Some OIDC identity providers may provide a random value in the "sub"
field instead of an identifying ID. In this case, it may be a good
idea to fallback to matching the user on its email field.
* 🐛(frontend) update access role
Currently, when you click on modify a role, the roles displayed are not the
correct ones. We always took the role of the connected user.
Additionally, there was a warning and a ban on changing roles if you were the
last owner, but it was decided that it was the backend that was throwing the
error and the action was allowed.
* ✅(frontend) adapt tests
We adapt the tests. Remove the check if you are the last owner and use the new
props inside the relevant tests
