62 lines
3.5 KiB
Markdown
62 lines
3.5 KiB
Markdown
# 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).
|