Mengapa dan bagaimanakah anda patut menggunakan model pengguna tersuai?

Question

Accepted Answer

**Model pengguna tersuai** menggantikan `User` lalai Django untuk memenuhi keperluan aplikasi anda — menambah medan, menukar pengenal log masuk (cth. e-mel dan bukannya nama pengguna), atau menyesuaikan tingkah laku. Nasihat kritikal yang kerap diulang: sediakan model pengguna tersuai **pada permulaan** projek, walaupun anda belum memerlukan perubahan lagi, kerana mengubahnya kemudian amat menyakitkan.

## Mengapa: User lalai terhad dan sukar diubah kemudian

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

## Sebab kritikal untuk melakukannya DAHULU

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

Ini ialah pengajaran praktikal utama: ia hampir tidak menelan kos untuk menyediakan model pengguna tersuai pada hari pertama, tetapi memasangnya semula pada projek yang sudah mantap ialah usaha besar yang terdedah-ralat — jadi anda melakukannya di awal sebagai insurans.

## Bagaimana: mengembangkan AbstractUser (cara mudah)

```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` mengekalkan semua medan lalai dan jentera auth Django — anda hanya menambah medan. Pendekatan yang paling ringkas dan paling biasa.

## Bagaimana: AbstractBaseUser (kawalan penuh, cth. log masuk e-mel)

```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` memberikan kawalan penuh terhadap model pengguna (cth. mengeluarkan nama pengguna sepenuhnya untuk log masuk e-mel sahaja) — lebih banyak kerja, tetapi fleksibiliti maksimum.

## Merujuk model pengguna dengan betul

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

Sentiasa rujuk model pengguna melalui `settings.AUTH_USER_MODEL` (dalam model) dan `get_user_model()` (dalam kod), tidak sekali-kali dengan mengimport `User` lalai secara langsung — supaya kod anda berfungsi dengan model tersuai.

## Mengapa ia penting

Menggunakan model pengguna tersuai ialah pengetahuan penting dengan satu pengajaran praktikal kritikal yang kerap ditekankan yang patut dihayati oleh setiap pembangun Django: **sediakannya pada permulaan setiap projek**.

Sebab ini sangat penting ialah ketidakseimbangan teruk dalam tahap kesukaran — mentakrifkan model pengguna tersuai pada hari pertama (walaupun subkelas `AbstractUser` kosong) hampir tidak menelan kos dan menyediakan fleksibiliti yang tidak ternilai, manakala beralih kepada model pengguna tersuai *selepas* projek mempunyai migrasi dan data amat menyakitkan dan berisiko, kerana model User dirujuk secara mendalam di seluruh Django (pengesahan, admin, sesi) dan oleh foreign key merentasi keseluruhan pangkalan data anda, memerlukan migrasi data yang kompleks dan terdedah-ralat untuk mengubahnya.

Inilah sebabnya dokumentasi Django sendiri amat mengesyorkan model pengguna tersuai untuk setiap projek baharu, tanpa mengira keperluan segera — ia ialah insurans terhadap mimpi ngeri migrasi pada masa hadapan.

Di luar nasihat masa kritikal ini, memahami *cara* mencipta model pengguna tersuai — **`AbstractUser`** untuk sekadar menambah medan sambil mengekalkan tingkah laku auth Django (kes mudah yang biasa), dan **`AbstractBaseUser`** untuk kawalan penuh seperti log masuk berasaskan-e-mel (mengeluarkan nama pengguna sepenuhnya) — adalah berharga untuk memenuhi keperluan aplikasi sebenar (medan pengguna tambahan, pengenal log masuk alternatif, auth tersuai).

Sama pentingnya ialah mengetahui untuk **merujuk model pengguna dengan betul** (melalui `settings.AUTH_USER_MODEL` dan `get_user_model()`, tidak sekali-kali import langsung) supaya kod berfungsi dengan apa jua model pengguna yang dikonfigurasi.

Kerana hampir setiap aplikasi sebenar mempunyai keperluan khusus-pengguna di luar tetapan lalai Django (dan walaupun yang tidak akan mendapat manfaat daripada fleksibiliti itu), dan kerana kos tidak menyediakan ini di awal sangat tinggi, memahami model pengguna tersuai — terutamanya keperluan mutlak untuk menetapkan satu pada permulaan projek — ialah pengetahuan penting yang kritikal secara praktikal yang mencegah kesilapan peringkat projek yang biasa dan serius, menjadikannya satu cebisan kebijaksanaan amalan terbaik Django yang kerap dipetik.