Dlaczego i jak powinieneś używać niestandardowego modelu użytkownika?

Question

Accepted Answer

**Niestandardowy model użytkownika** zastępuje domyślny `User` Django'a, aby dostosować się do potrzeb aplikacji — dodając pola, zmieniając identyfikator logowania (np. e-mail zamiast nazwy użytkownika) lub dostosowując zachowanie. Krytyczna, często powtarzana rada: skonfiguruj niestandardowy model użytkownika **na samym początku** projektu, nawet jeśli nie potrzebujesz zmian teraz, ponieważ zmiana go później jest niezwykle bolesna.

## Dlaczego to ważne

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

## Krytyczny powód, aby zrobić to najpierw

```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 jest kluczowa praktyczna lekcja: konfiguracja niestandardowego modelu użytkownika w pierwszym dniu kosztuje prawie nic, ale dodanie go do ugruntowanego projektu to poważne i podatne na błędy przedsięwzięcie — dlatego robisz to z góry jako ubezpieczenie.

## Jak: rozszerzanie AbstractUser (łatwy sposób)

```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` zachowuje wszystkie domyślne pola Django'a i mechanizm uwierzytelniania — po prostu dodajesz pola. Najprostsze, najczęstsze podejście.

## Jak: AbstractBaseUser (pełna kontrola, np. logowanie e-mailem)

```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 pełną kontrolę nad modelem użytkownika (np. usunięcie nazwy użytkownika całkowicie na rzecz logowania tylko e-mailem) — więcej pracy, ale maksymalna elastyczność.

## Odwołanie do modelu użytkownika

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

Zawsze odwołuj się do modelu użytkownika za pośrednictwem `settings.AUTH_USER_MODEL` (w modelach) i `get_user_model()` (w kodzie), nigdy nie importując bezpośrednio domyślnego `User` — tak że Twój kod współpracuje z niestandardowym modelem.

## Dlaczego to ma znaczenie

Korzystanie z niestandardowego modelu użytkownika to ważna wiedza z krytyczną, często podkreślaną praktyczną lekcją, którą każdy programista Django powinien przyswoić sobie: **skonfiguruj go na samym początku każdego projektu**.

Powód, dla którego to ma tak duże znaczenie, to poważna asymetria w trudności — zdefiniowanie niestandardowego modelu użytkownika w pierwszym dniu (nawet pusta podklasa `AbstractUser`) kosztuje prawie nic i zapewnia nieocenioną elastyczność, podczas gdy przejście na niestandardowy model użytkownika *po* tym, jak projekt ma migracje i dane, jest niezwykle bolesne i ryzykowne, ponieważ model User jest głęboko referencjonowany w całym Django (uwierzytelnianie, admin, sesje) i przez klucze obce w całej bazie danych, wymagając złożonych, podatnych na błędy migracji danych, aby to zmienić.

Dlatego właśnie dokumentacja Django zdecydowanie rekomenduje niestandardowy model użytkownika dla każdego nowego projektu, niezależnie od natychmiastowej potrzeby — to ubezpieczenie na wypadek przyszłej migracjnej nocy.

Poza tą krytyczną poradą dotyczącą czasu, zrozumienie *jak* tworzyć niestandardowe modele użytkowników — **`AbstractUser`** do zwykłego dodawania pól przy zachowaniu zachowania uwierzytelniania Django (powszechny, łatwy przypadek) i **`AbstractBaseUser`** do pełnej kontroli, takiej jak logowanie oparte na e-mailu (całkowite usunięcie nazwy użytkownika) — jest cenne do spełniania rzeczywistych wymagań aplikacji (dodatkowe pola użytkownika, alternatywne identyfikatory logowania, niestandardowe uwierzytelnianie).

Równie ważne jest wiedzenie, jak **odwołać się do modelu użytkownika prawidłowo** (poprzez `settings.AUTH_USER_MODEL` i `get_user_model()`, nigdy bezpośredniego importu), aby kod działał z dowolnie skonfigurowanym modelem użytkownika.

Ponieważ prawie każda rzeczywista aplikacja ma potrzeby specyficzne dla użytkownika poza domyślnymi ustawieniami Django (i nawet te, które ich nie mają, czerpią korzyści z elastyczności), a ponieważ koszt nie skonfigurowania tego wcześnie jest tak wysoki, zrozumienie niestandardowych modeli użytkowników — szczególnie imperażu ustanowienia jednego na początek projektu — to ważna, praktycznie krytyczna wiedza, która zapobiega częstemu i poważnemu błędowi na poziomie projektu, czyniąc to często cytowaną częścią najlepszych praktyk Django.