PB-1045 Add user model and GET endpoints

[asteiner-swisstopo]

This adds the GET endpoints for users in service-control. The POST endpoint is done in a subsequent PR in order to unblock the works on adding the users to Cognito (see PB-1044).

Summary of changes:

1. New app "access" as defined in the API specs.
2. New Django model User with

    username: CharField
    first_name: CharField
    last_name: CharField
    email: EmailField
    provider: ForeignKey

   ℹ️ The fields created and updated that are listed in the API specs are left out for the moment.
   ℹ️ We defined our own user model instead of taking the one from django.contrib.auth. This is to keep a minimal model and avoid confusion that Django authentication has anything to say here.
3. New endpoints:
   1. users/{user_id}: Returns a specific user.
      ℹ️ For the response schema, I considered setting type EmailStr for field UserSchema.email. I didn't do so because that would introduce an additional dependency: email-validator. I thought that the validation in the Django model is enough but happy to adjust if the response should also be validated.
      ℹ️ Also for the response schema UserSchema, I considered inheriting from ninja.ModelSchema. This would have allowed me to avoid repeating all the fields and using UserSchema(model).from_orm() to convert the model to the schema. I couldn't manage to get this working because Django somehow creates implicit fields like provider_id_id (note the double _id appendix). Instead, I added a function user_to_response similar to the other models. Please let me know if you see a way how to define the model/schema fields such that we can make use of ninja.ModelSchema.
   2. users: Returns all users.

Example response for users/123:

{
    "username": "dude",
    "first_name": "Jeffrey",
    "last_name": "Lebowski",
    "email": "[email protected]",
    "provider_id": 42,
}

Example response for users:

{
    "items": [
        {
            "username": "dude",
            "first_name": "Jeffrey",
            "last_name": "Lebowski",
            "email": "[email protected]",
            "provider_id": 42,
        },
        {
            "username": "veteran",
            "first_name": "Walter",
            "last_name": "Sobchak",
            "email": "[email protected]",
            "provider_id": 42,
        },
    ]
}

[schtibe]

Nice, just little remarks.
Now go bowling!

[msom]

Looks good.

Regarding django vs. ninja validation: Have you tried what happens if in invalid email is provided (might be worth a test)? My guess is that relying on the django validator will ultimately result in an aborted transaction, where using the ninja validator will probably not. If true, using the ninja validator might be a bit cleaner.

[asteiner-swisstopo]

Looks good.

Regarding django vs. ninja validation: Have you tried what happens if in invalid email is provided (might be worth a test)? My guess is that relying on the django validator will ultimately result in an aborted transaction, where using the ninja validator will probably not. If true, using the ninja validator might be a bit cleaner.

As discussed in chat, Django's EmailField only affects form validation. Not model validation. So no exception is raised when saving a User with an invalid email. I added a corresponding test to demonstrate that.

For the moment, we agreed on taking the extra dependency and add email-validator such that we can use pydantics EmailStr. To be discussed in the team whether we want to validate only input/output at the endpoints or also when storing data to the DB.

[asteiner-swisstopo]

Hi @schtibe and @msom,

I have adapted the following after our discussion yesterday:

1. Add field User.username as primary key.
2. Leave User.first_name / User.last_name as it is.
3. Overwrite User.clean() and User.save() such that the email es validated every time we try to write to the database.
4. Remove the type checks in UserSchema.email and User.email. Both are not necessary anymore with the validation in User.clean(). This also allows us to avoid the additional dependency email-validator.

Would you mind having another look please? 😇