Skip to content

Mixins & Signals

This section documents implicit behavior in Project logic that runs without being explicitly called .

These are the most dangerous areas to change blindly , so understanding them is critical.

PART A — MIXINS (Access Control & Role Enforcement)

Mixins are used to enforce role boundaries and prevent cross-panel access .

1. IsCustomerMixin

Used in

  • Customer profile
  • Customer products
  • Customer supports
  • Customer orders

What it enforces

  • User must be:
  • Authenticated
  • is_customer = True

Execution behavior

  1. Runs before view logic
  2. If authenticated but not customer → returns 403 HTML page
  3. If unauthenticated → redirects to login

Why it exists

  • Prevent seller/admin users from accessing customer-only routes
  • Avoid silent permission leaks

2. IsSellerMixin

Used in

  • Seller dashboard
  • Product management
  • Category management
  • Support management
  • Short URL management

What it enforces

  • User must be:
  • Authenticated
  • is_seller = True

Execution behavior

  1. Runs before view logic
  2. If role mismatch → returns 403 page
  3. If not logged in → redirects to login

Why it exists

  • Hard separation between buyer UI and seller business UI
  • Critical for multi-tenant safety

3. Generic View + Mixin Pattern

Pattern used everywhere:

LoginRequiredMixin
+ RoleMixin
+ GenericView

Why this matters

  • Authentication
  • Authorization
  • Business logic

are layered , not mixed.

If something breaks:

  • First check mixin
  • Then check generic base view
  • Then check app-specific view

PART B — SIGNALS (Automatic Side Effects)

Signals are used for cross-system synchronization .

They are intentionally limited and high-impact .

1. User → Dodo Customer Creation

Signal

  • post_save(User)

Triggered when

  • A new user is created (registration, admin, migration, etc.)

What happens

  1. User is created in Django
  2. Dodo API is called
  3. External Dodo Customer is created
  4. DodoCustomer row is stored locally

Why it exists

  • Payments require a customer entity
  • Keeps payment logic out of auth views

Failure behavior

  • Failure is logged
  • User creation does NOT fail
  • Payment will fail later if customer missing

2. Product → Dodo Product Creation

Signal

  • post_save(Product) (created = True)

Triggered when

  • Seller creates a new product

What happens

  1. Product saved in DB
  2. Dodo Product created
  3. Dodo Product ID stored locally

Why it exists

  • Ensures product is purchasable immediately
  • Removes manual payment configuration

3. Product → Dodo Product Update

Signal

  • post_save(Product) (created = False)

Triggered when

  • Seller updates:
  • Title
  • Price
  • Selling price

What happens

  • Corresponding Dodo product is updated

Why it exists

  • Price consistency across systems
  • Avoids mismatch between UI and checkout

4. Product → Dodo Product Archive

Signal

  • pre_delete(Product)

Triggered when

  • Seller deletes a product

What happens

  • Product is archived on Dodo
  • Prevents further purchases

Important rule

  • Product deletion is blocked if purchases exist
  • Signal is last safety net

5. Product Slug Auto-Generation

Signal

  • pre_save(Product)

Triggered when

  • Product is saved without a slug

What happens

  • Slug auto-generated using:
  • Title prefix
  • Random suffix

Why it exists

  • SEO-safe URLs
  • Prevent slug collisions
  • Allow seller to skip slug field

6. Product Category Slug Generation

Signal

  • pre_save(ProductCategory)

Triggered when

  • Category saved without slug

What happens

  • Slug auto-generated from name

7. Product File Cleanup

Signal

  • post_delete(Product)

Triggered when

  • Product deleted successfully

What happens

  • Physical product file is deleted
  • Prevents orphaned files in storage

PART C — WHY THIS DESIGN MATTERS

What Signals Are Used For

  • External system sync
  • Auto-generated identifiers
  • Cleanup operations

What Signals Are NOT Used For

  • Business rules
  • Permission checks
  • UI logic

This is intentional.

PART D — DANGER ZONES (Read Carefully)

⚠️ Do NOT disable signals unless you know the impact

Change Side Effect
Disable User → Dodo signal Payments break
Disable Product → Dodo signal Checkout breaks
Disable slug signal URLs break
Disable delete cleanup Storage leaks

PART E — Customization Guidelines

Safe customizations

  • Add new role mixins
  • Extend seller/customer permissions
  • Add new signals for new integrations

Unsafe customizations

  • Removing existing signals
  • Adding heavy logic inside signals
  • Making signals transactional across APIs

Execution Summary

Area Behavior
Mixins Enforce role & access
Signals Sync systems automatically
Failure handling Logged, non-blocking
Side effects Intentional & minimal