Zakaj in kako bi moral/a uporabiti custom user model?

Question

Accepted Answer

**Custom user model** nadomešča Django's privzeti `User` model, da se prilagodi potrebam vaše aplikacije — dodajanje polj, sprememba identifikatorja za prijavo (npr. e-pošta namesto uporabniškega imena) ali prilagajanje vedenja. Kritičen in pogosto ponovljen nasvet: nastavite custom user model **na samem začetku** projekta, tudi če sprememb ne potrebujete še, ker je sprememba pozneje izjemno boleča.

## Zakaj: privzeti User je omejen in ga je težko spremeniti pozneje

```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čen razlog, da to naredite PRVO

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

To je ključna praktična lekcija: nastavitev custom user modela na prvi dan skoraj nič ne stane, vendar je dodajanje enega na že ustaljeni projekt velika, napaka-naklonjenja naloga — zato to naredite vnaprej kot zavarovanje.

## Kako: razširitev AbstractUser (enostaven 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` ohrani vsa Django's privzeta polja in mehanizme avtentifikacije — samo dodate polja. Najenostavnejši in najbolj pogost pristop.

## Kako: AbstractBaseUser (polna kontrola, npr. prijava po e-pošti)

```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` vam da popolno kontrolo nad user modelom (npr. odstranitev uporabniškega imena za prijavo samo po e-pošti) — več dela, toda največja fleksibilnost.

## Pravilno sklicevanje na 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
```

Se vedno sklicujte na user model preko `settings.AUTH_USER_MODEL` (v modelih) in `get_user_model()` (v kodi), nikoli z direktnim uvozom privzetega `User` — tako vaša koda deluje s custom modelom.

## Zakaj je to pomembno

Uporaba custom user modela je pomembno znanje s kritično, pogosto poudarjeno praktično lekcijo, ki bi jo moral/a vsak Django razvojnik/ka internalizirati: **nastavite ga na samem začetku vsakega projekta**.

Razlog, da je to tako pomembno, je huda asimetrija v težavnosti — opredelitev custom user modela na prvi dan (tudi prazen `AbstractUser` podrazred) skoraj nič ne stane in zagotavlja neprecenljivo fleksibilnost, medtem ko je prehod na custom user model *po tem*, ko ima projekt migracije in podatke, izjemno boleč in tvegan, ker je User model globoko referenčiran po vsem Django-u (avtentifikacija, admin, seje) in s tujimi ključi po celotni bazi podatkov, kar zahteva zapletene, napaka-naklonjene migracije podatkov za spremembo.

To je razlog, zakaj Django-ova lastna dokumentacija močno priporoča custom user model za vsak novi projekt, ne glede na trenutno potrebo — to je zavarovanje pred prihodnjimi migracijski nočami.

Poleg te kritične časovne napotke je razumevanje *kako* ustvariti custom user modele — **`AbstractUser`** za preprosto dodajanje polj ob ohranitvi Django-jevega vedenja avtentifikacije (pogost, enostaven primer) in **`AbstractBaseUser`** za popolno kontrolo, kot je prijava po e-pošti (odstranitev uporabniškega imena v celoti) — dragoceno za doseganje resničnih zahtev aplikacije (dodatna user polja, alternativni identifikatorji za prijavo, custom avtentifikacija).

Enako pomembno je vedeti, da **pravilno sklicujete na user model** (preko `settings.AUTH_USER_MODEL` in `get_user_model()`, nikoli direktnega uvoza), da koda deluje s katerokoli konfiguriranim user modelom.

Ker skoraj vsaka resnična aplikacija ima uporabnik-specifične potrebe izven Django-jevih privzetkov (in tudi tiste, ki jih nimajo, imajo korist od fleksibilnosti), in ker je strošek nenastavljanja tega zgodaj tako visok, razumevanje custom user modelov — posebej imperativ vzpostavitve enega na začetku projekta — je pomembno, praktično-kritično znanje, ki preprečuje pogosto in resno napako na ravni projekta, kar ga naredi pogosto citirano bit Django best-practice modrosti.