Pse dhe si duhet të përdorni një model përdoruesi të personalizuar?

Question

Accepted Answer

Një **model përdoruesi i personalizuar** zëvendëson `User` parazgjedhje të Django për të përshtatur nevojat e aplikacionit tuaj — duke shtuar fusha, duke ndryshuar identifikuesin e hyrjes (p.sh. email në vend të username), ose duke përshtatur sjelljen. Këshilla kritike dhe e përsëritur shpesh: krijoni një model përdoruesi të personalizuar **në fillim të projektit**, madje edhe nëse nuk keni nevojë për ndryshime ende, sepse ndryshimi i tij më vonë është jashtëzakonisht i dhimbshëm.

## Pse: User parazgjedhje është i kufizuar dhe i vështirë për t'u ndryshuar më vonë

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

## Arsyeja kritike për ta bërë FILLIMISHT

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

Kjo është mësim praktik kyç: shtimi i një modeli përdoruesi të personalizuar në ditën e parë kushtojnë pothuajse asgjë, por përshtatja e njërit në një projekt të vendosur është një ndërmarrje kryesore dhe e prirur për gabime — kështu që e bëni atë paraprakisht si siguri.

## Si: zgjerimi i AbstractUser (mënyra e lehtë)

```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` mban të gjitha fushat parazgjedhje dhe mekanizmat e autentifikimit të Django — ju thjesht shtoni fusha. Qasja më e thjeshtë dhe më e zakonshme.

## Si: AbstractBaseUser (kontroll i plotë, p.sh. hyrje me email)

```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` jep kontroll të plotë mbi modelin e përdoruesit (p.sh. heqje e username plotësisht për hyrje vetëm me email) — më shumë punë, por fleksibilitet maksimal.

## Referencimi i modelit të përdoruesit siç duhet

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

Always reference the user model via `settings.AUTH_USER_MODEL` (në modele) dhe `get_user_model()` (në kod), asnjëherë duke importuar direkt `User` parazgjedhje — kështu që kodi juaj funksionon me modelin e personalizuar.

## Pse ka rëndësi

Përdorimi i një modeli përdoruesi të personalizuar është njohuri e rëndësishme me një mësim praktik kritik dhe shpesh të theksuar që çdo zhvilluesi Django duhet ta përvetësojë: **vendoseni atë në fillim të çdo projekti**.

Arsyeja për të cilën kjo është kaq e rëndësishme është asimetria e rëndë në vështirësi — përcaktimi i një modeli përdoruesi të personalizuar në ditën e parë (madje edhe një `AbstractUser` subclass të zbrazët) kushtojnë pothuajse asgjë dhe sigurojnë fleksibilitet të paçmuar, ndërsa kalimi në një model përdoruesi të personalizuar *pasi* projekti ka migrimi dhe të dhëna është jashtëzakonisht i dhimbshëm dhe rrezikshëm, sepse modeli i User-it është thellësisht referuar në të gjithë Django (autentifikimi, admin, seanca) dhe nga çelësat e jashtëm në të gjithë bazën tuaj të të dhënave, kërkojnë migrimi komplekse dhe të prirur për gabime për t'u ndryshuar.

Kjo është arsyeja pse dokumentacioni i vetë Django rekomandon fuqimisht një model përdoruesi të personalizuar për çdo projekt të ri, pavarësisht nga nevoja e menjëhershme — ito siguri kundër një nate migrimi në të ardhmen.

Për shkak të kësaj këshille kritike të kohës, të kuptuarit *si* të krijohet model përdoruesish të personalizuar — **`AbstractUser`** për thjesht shtimin e fushave ndërsa mbani sjelljen e autentifikimit të Django (rasti i zakonshëm, i lehtë), dhe **`AbstractBaseUser`** për kontroll të plotë si hyrja bazuar në email (heqja e username plotësisht) — është e vlefshme për të përmbushur kërkesat reale të aplikacionit (fusha shtesë të përdoruesit, identifikues alternative të hyrjes, autentifikimi custom).

Njësoj e rëndësishme është të dini të **referoj modelin e përdoruesit siç duhet** (nëpërmjet `settings.AUTH_USER_MODEL` dhe `get_user_model()`, asnjëherë një import direkt) kështu që kodi funksionon me cilido model përdoruesi i konfiguruar.

Sepse pothuajse çdo aplikacion real ka nevoja specifike të përdoruesit përtej parazgjedhjes të Django (dhe madje ato që nuk kanë përfitim nga fleksibilimi), dhe sepse kostoja e mos-vendosjes së kësaj herët është kaq e lartë, të kuptuarit e modeleve të përdoruesit të personalizuar — veçanërisht urdhri për të vendosur njërin në fillim të projektit — është njohuri e rëndësishme, praktikisht-kritike që parandalon një gabim të zakonshëm dhe serioze në nivel projekti, duke e bërë atë një pikë të cituar shpesh e mençurie më të mirë Django.