Zašto i kako biste trebali koristiti prilagođeni korisnički model?
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.
# 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
classUser(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.
