fixed a test that would fail because of random auth user name being
too close to tested names (assert would find 2 results instead of 1).
Setting the name of auth user should fix the issue permanently.
The use of a lazy function here make the Django migration
detector to generate a migration every time we run `makemigrations`.
This is not mandatory to have a lazy here as the settings are loaded
once at runtime beginning.
As the choices makes noop migrations, we directly use the setting in
the initial migration.
This adds the plugin system to easily manage
Organization related customizations. This first
plugin tries (best effort) to get a proper name
for the Organization, using its SIRET. This
is French specificities but another plugin can
be defined for other cases.
Use the common way to define permissions on the API.
Note: we keep here the notion of "public" contacts,
even if the API does not really allows that. The use
case is not clear for that, but we allow contact w/o
owner to be displayed.
Move the user <-> contact relation for "profile" to
the contact model.
Now the Contact model is the only one to point to
User (and not backward).
Contact:
- FK to User for the owner
- FK to User for the profile
To improve code readability, I propose to rename
the contact field `override`. This comes along
with the fact a contact should not not always
override another (it's the case were I only want
to create some personal contacts).
We make the full name mandatory and add a field to
allow user to store personnal notes on the contact.
This also make the "base" contact not mandatory because
user may want to create new contacts out of the blue.
To improve readability and code sharing we group all
APIs into the same "api" module for each application.
Next submodules might be "scim",
"resource_server_scim", ...
The only shared module is the "permissions" one for now.
When updating an Organization in the Django admin, the validator
falsly raises a "duplicated" error because it does not exclude the
current object from the database lookup.
We don't want every Service Provider to be able to request
every endpoint if those are not implementing a filtering on
the data returned. To prevent any data leak we enforce the
developers to manually "whitelist" each endpoint and add
the proper filtering when needed.
When we use the feature to get Organization registration
number, the claim contains this value and it does not
match with any user field.
I switched to a whitelist instead of a blacklist (and two
loops, with an if condition on each)
This commit removes the slug field from
the database, now the nullable migration is in
production and the field has been remove from
the code deployed.
FIXES#505
This allows, on a per user basis, the display of
features.
The main goal here is to allow Team admin or owner
to see the management views.
We also added the same for the two other features
(mailboxes and contacts)
This will be improved later if needed :)
After some reflexion, the use of a slug field raises to many
problems without being really needed.
One problem is the slug is made from the group name, but we
don't have unicity on this, so a user might be blocked without
any clue.
We also want to allow group names to be reused (which is already
allowed except for the automatic slug).
The unique ID that will be shared with Service Providers will be
the PK/UUID.
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
