Hvorfor og hvordan skal du bruge en custom user model?

Question

Accepted Answer

En **custom user model** erstatter Djangos standard `User` for at passe til dit applikations behov — ved at tilføje felter, ændre login-identifikator (f.eks. email i stedet for brugernavn) eller tilpasse adfærd. Det kritiske, ofte gentagne råd: opret en custom user model **helt fra starten** af et projekt, selv hvis du ikke har brug for ændringer endnu, fordi det at ændre det senere er ekstremt smertefuldt.

## Hvorfor: standard User er begrænset og svær at ændre senere

```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
```

## Den kritiske grund til at gøre det FØRST

```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.
```

Dette er den vigtigste praktiske lektie: det koster næsten intet at oprette en custom user model på dag et, men at tilføje det til et etableret projekt er en større, fejlproblematisk opgave — så du gør det på forhånd som forsikring.

## Hvordan: udvidelse af AbstractUser (den lette måde)

```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` bevarer alle Djangos standard felter og auth-mekanisme — du tilføjer bare felter. Den enkleste, mest almindelige tilgang.

## Hvordan: AbstractBaseUser (fuld kontrol, f.eks. email-login)

```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` giver fuld kontrol over user model (f.eks. fjernelse af brugernavn helt for kun email-login) — mere arbejde, men maksimal fleksibilitet.

## Korrekt reference til user model

```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
```

Referencer altid user modellen via `settings.AUTH_USER_MODEL` (i modeller) og `get_user_model()` (i kode), aldrig ved direkte import af standard `User` — så din kode fungerer med custom modellen.

## Hvorfor det betyder noget

At bruge en custom user model er vigtig viden med en kritisk, hyppigt understreget praktisk lektie, som hver Django-udvikler bør internalisere: **opret den helt fra starten af ethvert projekt**.

Grunden til at dette betyder så meget er den alvorlige asymmetri i vanskelighed — at definere en custom user model på dag et (selv en tom `AbstractUser` underklasse) koster næsten intet og giver uvurderlig fleksibilitet, mens skift til en custom user model *efter* at projektet har migrationer og data er ekstremt smertefuldt og risikabelt, fordi User-modellen er dybt refereret gennem hele Django (autentificering, admin, sessions) og af foreign keys på tværs af hele din database, hvilket kræver komplekse, fejlproblematiske datamigrationer at ændre.

Dette er grunden til at Djangos egen dokumentation stærkt anbefaler en custom user model for ethvert nyt projekt, uanset umiddelbare behov — det er forsikring mod en fremtidig migrerings marerid.

Ud over dette kritiske timing-råd er forståelse af *hvordan* man opretter custom user modeller — **`AbstractUser`** for blot at tilføje felter mens man bevarer Djangos auth-adfærd (det almindelige, lette tilfælde), og **`AbstractBaseUser`** for fuld kontrol som email-baseret login (fuldstændig fjernelse af brugernavn) — værdifuldt for at opfylde virkelige programkrav (ekstra user-felter, alternative login-identifikatorer, custom auth).

Ligeledes vigtig er viden om at **reference til user modellen korrekt** (via `settings.AUTH_USER_MODEL` og `get_user_model()`, aldrig direkte import) så kode fungerer med uanset hvilken user model der er konfigureret.

Fordi næsten hver virkelig applikation har brugerspecifikke behov ud over Djangos standarder (og selv dem der ikke gør, drager fordel af fleksibiliteten), og fordi omkostningen ved ikke at sætte dette op tidligt er så høj, er forståelse af custom user modeller — især imperativet for at etablere en ved projekt start — vigtig, praktisk-kritisk viden, der forhindrer en almindelig og alvorlig fejl på projektniveau, hvilket gør det til et hyppigt nævnt stykke Django best-practice visdom.