لماذا وكيف يجب استخدام نموذج مستخدم مخصص؟

Question

Accepted Answer

**نموذج المستخدم المخصص** يحل محل `User` الافتراضي في Django ليناسب احتياجات تطبيقك — بإضافة حقول، أو تغيير معرّف تسجيل الدخول (مثل البريد الإلكتروني بدلاً من اسم المستخدم)، أو تخصيص السلوك. النصيحة الحرجة والمتكررة: قم بإعداد نموذج مستخدم مخصص **في بداية المشروع تماماً**، حتى لو لم تحتج إلى تغييرات الآن، لأن تغييره لاحقاً أمر بالغ الصعوبة.

## لماذا: نموذج المستخدم الافتراضي محدود وصعب التغيير لاحقاً

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

## السبب الحرج للقيام به أولاً

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

هذا هو الدرس العملي الأساسي: إعداد نموذج مستخدم مخصص في اليوم الأول لا يكلف شيئاً تقريباً، لكن إضافة واحد إلى مشروع راسخ بالفعل هو عملية كبرى وعرضة للأخطاء — لذلك تقوم به مقدماً كتأمين.

## الطريقة: توسيع AbstractUser (الطريقة السهلة)

```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` يحتفظ بجميع الحقول الافتراضية لـ Django وآليات المصادقة — تضيف فقط حقولاً إضافية. الأسلوب الأبسط والأكثر شيوعاً.

## AbstractBaseUser (تحكم كامل، مثل تسجيل دخول عبر البريد الإلكتروني)

```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` يمنحك تحكماً كاملاً على نموذج المستخدم (مثل إزالة اسم المستخدم بالكامل لتسجيل دخول عبر البريد الإلكتروني فقط) — يتطلب عملاً أكثر، لكن مرونة قصوى.

## الإشارة إلى نموذج المستخدم بشكل صحيح

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

احرص دائماً على الإشارة إلى نموذج المستخدم عبر `settings.AUTH_USER_MODEL` (في النماذج) و `get_user_model()` (في الكود)، وليس عبر استيراد `User` الافتراضي مباشرة — بحيث يعمل كودك مع النموذج المخصص.

## أهمية هذا

استخدام نموذج مستخدم مخصص هو معرفة مهمة مع درس عملي حرج يتم التأكيد عليه بشكل متكرر يجب على كل مطور Django أن يستوعبه: **قم بإعداده في بداية كل مشروع**.

السبب في أهمية هذا كثيراً هو عدم التناسب الشديد في الصعوبة — تعريف نموذج مستخدم مخصص في اليوم الأول (حتى مجرد فئة فرعية `AbstractUser` فارغة) لا يكلف شيئاً تقريباً ويوفر مرونة لا تقدر بثمن، في حين أن التبديل إلى نموذج مستخدم مخصص *بعد* أن يكون المشروع قد تم بالفعل مع الترحيلات والبيانات أمر بالغ الصعوبة والخطورة، لأن نموذج المستخدم مرجعي بعمق عبر Django (المصادقة، المسؤول، الجلسات) وعبر المفاتيح الخارجية في جميع أنحاء قاعدة البيانات الخاصة بك، مما يتطلب ترحيلات بيانات معقدة وعرضة للأخطاء للتغيير.

هذا هو السبب في أن توثيق Django نفسه توصي بشدة بنموذج مستخدم مخصص لكل مشروع جديد، بغض النظر عن الحاجة الفورية — إنه تأمين ضد كابوس الترحيل المستقبلي.

بعيداً عن هذه النصيحة الحرجة بشأن التوقيت، فإن فهم *كيفية* إنشاء نماذج مستخدمين مخصصين — **`AbstractUser`** لإضافة حقول ببساطة مع الحفاظ على سلوك مصادقة Django (الحالة الشائعة والسهلة)، و **`AbstractBaseUser`** للتحكم الكامل مثل تسجيل الدخول القائم على البريد الإلكتروني (إزالة اسم المستخدم بالكامل) — قيم لتلبية متطلبات التطبيق الحقيقية (حقول مستخدم إضافية، معرفات تسجيل دخول بديلة، مصادقة مخصصة).

من المهم بنفس القدر معرفة **الإشارة إلى نموذج المستخدم بشكل صحيح** (عبر `settings.AUTH_USER_MODEL` و `get_user_model()`، وليس استيراداً مباشراً) بحيث يعمل الكود مع نموذج المستخدم أياً كان المكوّن.

لأن تقريباً كل تطبيق حقيقي لديه احتياجات خاصة بالمستخدم تتجاوز افتراضيات Django (وحتى تلك التي لا تفعل تستفيد من المرونة)، ولأن تكلفة عدم إعداد هذا مبكراً عالية جداً، فإن فهم نماذج المستخدمين المخصصين — خاصة الضرورة الملحة لإنشاء واحد في بداية المشروع — معرفة حرجة عملياً توقف خطأ شائع وخطير على مستوى المشروع، مما يجعله قطعة معروفة بشكل متكرر من حكمة أفضل الممارسات في Django.