igny8/docs/50-DEPLOYMENT/DATABASE-MIGRATIONS.md

Migration Notes

Purpose

Track significant schema or data migrations, with references to the scripts present in the repo that have been used to adjust data or structure.

Code Locations (exact paths)

• Migration/utility scripts (repo root backend/):
  • verify_migrations.py, verify_status_fixes.py, verify_taxonomy.py
  • fix_* scripts (e.g., fix_cluster_status.py, fix_content_types.py, fix_integration_site_url.py, fix_sync.py, fix_taxonomy_relationships.py)
  • rename_fields_migration.sql
  • inject_test_data.py, sync_idea_status.py, check_recent_keywords.py, check_api_response.py, diagnose_generate_content.py
• Django migrations: backend/igny8_core/**/migrations/ (per app)

High-Level Responsibilities

• Capture when ad-hoc fixes or manual SQL were required so future migrations can account for existing state.
• Provide guidance on verifying migrations after code changes.

Detailed Behavior

• Python fix/verify scripts operate against live DBs to patch or validate data (names indicate target domain: clusters/content/integration/taxonomy).
• rename_fields_migration.sql suggests a manual SQL rename was performed; ensure corresponding Django migration exists or is applied.
• verify_* scripts check consistency after migrations or data changes.
• These scripts are not automatically executed; they are run manually as needed.

Execution Flow (Recommended)

• Prefer standard Django migrations first: python manage.py makemigrations && python manage.py migrate.
• For data issues covered by fix scripts:
  • Review script purpose and run in controlled environment (staging) before production.
  • Take DB backup before executing manual SQL or fix scripts.
• After applying migrations/fixes, run verify scripts to confirm expected state.

Cross-Module Interactions

• Scripts touch planner/writer/integration data; impacts automation and billing indirectly if content/status changes alter usage.

State Transitions (if applicable)

• DB schema changes via migrations; data patches via scripts.

Error Handling

• Scripts log/print outputs; failures will surface during execution; no centralized handler.

Tenancy Rules

• All scripts should respect account/site scoping; review code before running to ensure filters exist or add them.

Billing Rules (if applicable)

• None directly; data corrections may affect content/automation counts but not credit logs.

Background Tasks / Schedulers (if applicable)

• None; scripts are on-demand.

Key Design Considerations

• Keep fix/verify scripts version-controlled but treat them as one-off tools; remove or archive obsolete scripts.
• Ensure Django migrations are the source of truth for schema; manual SQL should be mirrored in migrations.

How Developers Should Work With This Module

• Before running any fix/verify script, read it and constrain to target account/site if possible.
• Add notes here when new manual interventions occur, including date/purpose and scripts used.

Recent Hardening (Dec 2025)

• Throttling bypass for authenticated users to prevent user-facing 429s.
• AI keys fallback: OpenAI/Runware pulled from system account (aws-admin/default-account/default) or Django settings if tenant key absent.
• Integration settings restricted to system account or developer (IsSystemAccountOrDeveloper backend guard, AdminGuard frontend).
• DRF default permissions tightened to authenticated + tenant access (IsAuthenticatedAndActive, HasTenantAccess); public endpoints must override explicitly (e.g., AuthViewSet).