Miksi ja miten sinun tulisi käyttää mukautettua käyttäjämallia?

Question

Accepted Answer

**Mukautettu käyttäjämalli** korvaa Djangon oletuskäyttäjän (`User`) sovelluksesi tarpeisiin — lisäämällä kenttiä, muuttamalla kirjautumistunnistetta (esim. sähköposti käyttäjänimen sijaan) tai mukauttamalla käyttäytymistä. Kriittinen, usein toistettu neuvo: aseta mukautettu käyttäjämalli **aivan projektin alussa**, vaikka et tarvitsisi muutoksia vielä, koska sen muuttaminen myöhemmin on erittäin vaikeaa.

## Miksi: oletuskäyttäjä on rajoittunut ja vaikea muuttaa myöhemmin

```text
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
  ✓ Email-based login (no username)
  ✓ Extra fields (phone, avatar, role, preferences) on the user itself
  ✓ Custom authentication behavior
```

## Kriittinen syy tehdä se ENSIN

```text
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
   referenced by auth, admin, sessions, foreign keys throughout the database.
   Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
   even an empty one, so you can extend it freely later. Django's docs strongly
   recommend this for EVERY new project.
```

Tämä on avainopetus: mukautetun käyttäjämallin asettaminen ensimmäisenä päivänä maksaa lähes mitään, mutta sen lisääminen jälkikäteen vakiintuneeseen projektiin on suuri, virheille altis toimenpide — joten teet sen etukäteen vakuutuksena.

## Miten: AbstractUser-laajennos (helppo tapa)

```python
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    phone = models.CharField(max_length=20, blank=True)
    avatar = models.ImageField(upload_to="avatars/", blank=True)
    is_premium = models.BooleanField(default=False)
```

```python
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
```

`AbstractUser` säilyttää kaikki Djangon oletuskentät ja auth-mekanismit — vain lisäät kenttiä. Yksinkertaisin, yleisin lähestymistapa.

## Miten: AbstractBaseUser (täysi kontrolli, esim. sähköpostilla kirjautuminen)

```python
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin

class User(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(unique=True)
    USERNAME_FIELD = "email"          # log in with EMAIL instead of username
    REQUIRED_FIELDS = []
    objects = CustomUserManager()     # a manager defining create_user/create_superuser
```

`AbstractBaseUser` antaa täyden kontrollin käyttäjämallin yli (esim. käyttäjänimen poistaminen kokonaan vain sähköpostiin perustuvaa kirjautumista varten) — enemmän työtä, mutta suurin joustavuus.

## Käyttäjämallin oikea viittaaminen

```python
from django.conf import settings
from django.contrib.auth import get_user_model

# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)

# in code — get the active user model dynamically
User = get_user_model()              # NOT a direct import of the default User
```

Viittaa aina käyttäjämalliin `settings.AUTH_USER_MODEL`-kautta (malleissa) ja `get_user_model()`-funktion kautta (koodissa), ei koskaan tuomalla oletuskäyttäjää suoraan — jotta koodisi toimii mukautetun mallin kanssa.

## Miksi se on tärkeää

Mukautetun käyttäjämallin käyttäminen on tärkeää tietoa, jossa on kriittinen, usein painotettu käytännöllinen opetus, jonka jokaisen Django-kehittäjän pitäisi sisäistää: **aseta se jokaisen projektin alussa**.

Syy, miksi tämä on niin tärkeää, on vaikeus-epäsymmetria — mukautetun käyttäjämallin määrittäminen ensimmäisenä päivänä (jopa tyhjä `AbstractUser`-aliluokka) maksaa lähes mitään ja tarjoaa arvokasta joustavuutta, kun taas siirtyminen mukautettuun käyttäjämalliin *sen jälkeen* kun projektilla on migraatiot ja data on äärimmäisen vaikeaa ja riskialtista, koska käyttäjämalli on syvästi referensoitu kaikkialla Djangossa (autentikointi, admin, istunnot) ja ulkomaisten avainten kautta koko tietokannassasi, mikä vaatii monimutkaisia, virheille alttiita datamigraatioita muuttamiseen.

Tämän vuoksi Django itse suosittelee voimakkaasti mukautettua käyttäjämallia jokaiseen uuteen projektiin huolimatta välittömästä tarpeesta — se on vakuutus tulevaa migraatiopahuutta vastaan.

Tälle kriittiselle ajoitus-neuvalle lisäksi ymmärtäminen siitä, **miten** luoda mukautettuja käyttäjämalleja — **`AbstractUser`** yksinkertaisesti kenttien lisäämiseen Djangon auth-käyttäytymisen säilyttäen (yleinen, helppo tapaus), ja **`AbstractBaseUser`** täydelle hallinnalle kuten sähköpostiin perustuvaan kirjautumiseen (käyttäjänimen poistaminen kokonaan) — on arvokas tosielämän sovelluksen vaatimusten täyttämiseksi (lisäkäyttäjäkentät, vaihtoehtoiset kirjautumistunnisteet, mukautettu auth).

Yhtä tärkeää on tietää käyttäjämallin **oikea viittaaminen** (`settings.AUTH_USER_MODEL`-kautta ja `get_user_model()`-funktion kautta, ei koskaan suoraa tuontia), jotta koodi toimii minkä tahansa konfiguraatiossaan olevan käyttäjämallin kanssa.

Koska lähes jokaisella todellisella sovelluksella on käyttäjäkohtaisia tarpeita Djangon oletusarvojen ulkopuolella (ja jopa niilla, joilla ei ole, hyötyvät joustavuudesta), ja koska kustannus siitä, että tätä ei aseteta alussa, on niin korkea, ymmärtäminen mukautetuista käyttäjämalleista — erityisesti imperatiivi perustaa sellainen projektinsa alussa — on tärkeää, käytännöllisesti kriittistä tietoa, joka estää yleisen ja vakavan projektitason virheen, mikä tekee siitä usein lainatun Django-parhaiden käytäntöjen tiedoista.