Zašto i kako biste trebali koristiti prilagođeni korisnički model?

Question

Accepted Answer

**Prilagođeni korisnički model** zamjenjuje Django-ov zadanu `User` klasu kako bi odgovarao potrebama vaše aplikacije — dodavanjem polja, promjenom identifikatora za prijavu (npr. email umjesto korisničkog imena) ili prilagođavanjem ponašanja. Kritično, često ponavljano savjet: postavite prilagođeni korisnički model **na samom početku** projekta, čak i ako još ne trebate izmjene, jer ga kasnije mijenjati je izuzetno komplizirano.

## Zašto: zadana User klasa je ograničena i teško je mijenjati je kasnije

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

## Kritičan razlog da to učinite PRVI

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

Ovo je ključna praktična lekcija: postavljanje prilagođenog korisničkog modela na prvi dan gotovo ništa ne košta, ali dodavanje jednog na uspostavljen projekt je veliki, podložan greškama posao — zato ga radiš unaprijed kao osiguranje.

## Kako: proširivanje AbstractUser (jednostavan način)

```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` zadržava sva Django-ova zadana polja i autentifikacijske mehanizme — samo trebate dodati polja. Najjednostavniji, najčešće korišteni pristup.

## Kako: AbstractBaseUser (puna kontrola, npr. prijava putem email-a)

```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` daje potpunu kontrolu nad korisničkim modelom (npr. uklanjanje korisničkog imena za prijavu samo putem email-a) — više posla, ali maksimalna fleksibilnost.

## Ispravna referenciranja na korisnički 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
```

Alati referenciranja na korisnički model putem `settings.AUTH_USER_MODEL` (u modelima) i `get_user_model()` (u kodu), nikada ne uvozite izravno zadanu `User` klasu — tako da vaš kod radi s prilagođenim modelom.

## Zašto je to važno

Korištenje prilagođenog korisničkog modela je važno znanje s kritičnom, često naglašavnom praktičnom lekcijom koju bi svaki Django razvojni inženjer trebao internalizirati: **postavite ga na samom početku svakog projekta**.

Razlog zbog kojeg je to toliko važno je ozbiljna asimetrija u težini — definiranje prilagođenog korisničkog modela na prvi dan (čak i prazna `AbstractUser` podklasa) gotovo ništa ne košta i pruža neprocjenjivost fleksibilnost, dok prebacivanje na prilagođeni korisnički model *nakon* što projekt ima migracije i podatke je izuzetno bolno i rizično, jer se User model duboko referencira diljem Django-a (autentifikacija, administracija, sesije) i vanjskim ključevima diljem vaše cijele baze podataka, što zahtijeva složene, podložne greškama migracije podataka za promjenu.

To je razlog zašto Django-ova vlastita dokumentacija snažno preporučuje prilagođeni korisnički model za svaki novi projekt, bez obzira na neposrednu potrebu — to je osiguranje protiv budućeg mora migracije.

Osim ovog kritičnog savjeta o vremenu, razumijevanje *kako* kreirati prilagođene korisnijske modele — **`AbstractUser`** za jednostavno dodavanje polja dok se čuva Django-ovo ponašanje autentifikacije (čest, jednostavan slučaj), i **`AbstractBaseUser`** za potpunu kontrolu poput email-osnove prijave (uklanjanje korisničkog imena u potpunosti) — je dragocjeno za ispunjavanje stvarnih zahtjeva aplikacije (dodatna korisna polja, alternativni identifikatori prijave, prilagođena autentifikacija).

Jednako važno je znati **ispravno referencirati korisnički model** (putem `settings.AUTH_USER_MODEL` i `get_user_model()`, nikada izravnog uvoza) kako bi kod radio s bilo kojim konfiguriranim korisničkim modelom.

Zato što gotovo svaka stvarna aplikacija ima korisne specifične potrebe izvan Django-ovih zadanih postavki (i čak one koje nemaju koristi od fleksibilnosti), i zato što je cijena nepostavljanja ovoga rano toliko visoka, razumijevanje prilagođenih korisničkih modela — posebno imperativ za uspostavljanje jednog na početku projekta — je važno, praktično-kritično znanje koje sprječava čest i ozbiljan projekt-razini grešku, čineći ga često citiranim dijelom Django-ove best-practice mudrosti.