Hvorfor og hvordan bør du bruke en tilpasset brukermodell?

Question

Accepted Answer

En **tilpasset brukermodell** erstatter Djangos standard `User` for å passe til applikasjonens behov — legge til felt, endre påloggingsidentifikator (f.eks. e-post i stedet for brukernavn), eller tilpasse oppførsel. Det kritiske, ofte gjentatte rådet: sett opp en tilpasset brukermodell **helt fra starten** av et prosjekt, selv om du ikke trenger endringer ennå, fordi det er ekstremt vanskelig å endre det senere.

## Hvorfor: standard User er begrenset og vanskelig å endre 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 grunnen til å gjøre det FØ

```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 viktigste praktiske leksjonen: det koster nesten ingenting å sette opp en tilpasset brukermodell på dag en, men å legge til en på et etablert prosjekt er en stor, feilutsatt oppgave — så du gjør det på forhånd som forsikring.

## Hvordan: utvide AbstractUser (den enkle måten)

```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` beholder alle Djangos standardfelt og auth-mekanismer — du legger bare til felt. Den enkleste, mest vanlige tilnærmingen.

## Hvordan: AbstractBaseUser (full kontroll, f.eks. e-postpålogging)

```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` gir full kontroll over brukermodellen (f.eks. å fjerne brukernavn helt for e-postbasert pålogging) — mer arbeid, men maksimal fleksibilitet.

## Referere til brukermodellen korrekt

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

Referér alltid til brukermodellen via `settings.AUTH_USER_MODEL` (i modeller) og `get_user_model()` (i kode), aldri ved direkte import av standard `User` — slik at koden din fungerer med den tilpassede modellen.

## Hvorfor det betyr noe

Å bruke en tilpasset brukermodell er viktig kunnskap med en kritisk, ofte vektlagt praktisk leksjon som hver Django-utvikler bør internalisere: **sett den opp helt fra starten av hvert prosjekt**.

Grunnen til at dette betyr så mye er den alvorlige asymmetrien i vanskelighet — å definere en tilpasset brukermodell på dag en (selv en tom `AbstractUser`-underklasse) koster nesten ingenting og gir uvurderlig fleksibilitet, mens det å bytte til en tilpasset brukermodell *etter* at prosjektet har migrasjoner og data er ekstremt vanskelig og risikabelt, fordi User-modellen er dypt referert gjennom hele Django (autentisering, admin, sesjoner) og av fremmednøkler på tvers av hele databasen din, noe som krever komplekse, feilutsatte datamigrasjoner for å endre.

Dette er hvorfor Djangos egen dokumentasjon sterkt anbefaler en tilpasset brukermodell for hvert nytt prosjekt, uavhengig av umiddelbare behov — det er forsikring mot et fremtidig migrasjonsmareridt.

Utover dette kritiske timing-rådet er det å forstå *hvordan* du lager tilpassede brukermodeller — **`AbstractUser`** for å bare legge til felt mens du beholder Djangos auth-oppførsel (den vanlige, enkle saken), og **`AbstractBaseUser`** for full kontroll som e-postbasert pålogging (fjerne brukernavn helt) — verdifullt for å møte reelle programkrav (ekstra brukerfelter, alternative påloggingsidentifikatorer, tilpasset auth).

Like viktig er å vite at man skal **referere til brukermodellen korrekt** (via `settings.AUTH_USER_MODEL` og `get_user_model()`, aldri en direkte import) slik at koden fungerer med hvilken som helst konfigurert brukermodell.

Fordi nesten hver reell applikasjon har brukerspesifikke behov utover Djangos standarder (og selv de som ikke gjør det drar nytte av fleksibiliteten), og fordi kostnadene ved ikke å sette opp dette tidlig er så høye, er å forstå tilpassede brukermodeller — spesielt påbudet om å etablere en ved projektstart — viktig, praktisk-kritisk kunnskap som forhindrer en vanlig og alvorlig feil på prosjektnivå, noe som gjør det til en hyppig sitert del av Djangos best-practice-visdom.