- UserStatusView, EventModerationView, ReviewModerationView,
PartnerKYCReviewView: each state change now emits _audit_log()
inside the same transaction.atomic() block so the log stays
consistent with DB state on partial failure
- AuditLogMetricsView: GET /api/v1/rbac/audit-log/metrics/ returns
total/today/week/distinct_users/by_action_group; 60 s cache with
?nocache=1 bypass
- AuditLogListView: free-text search (Q over action/target/user),
page_size bounded to [1, 200]
- accounts.User.ALL_MODULES += 'audit-log';
StaffProfile.SCOPE_TO_MODULE['audit'] = 'audit-log'
- Migration 0005: composite indexes (action,-created_at) and
(target_type,target_id) on AuditLog
- admin_api/tests.py: 11 tests covering list shape, search,
page bounds, metrics shape+nocache, suspend/ban/reinstate
audit emission
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
POST /api/v1/notifications/schedules/<pk>/test-send/ accepts {"email": "..."},
renders the schedule's email, delivers to that address only with [TEST] prefix.
Does not touch last_run_at or last_status.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- user_account FK on Lead model (SET_NULL, related_name='submitted_leads')
- Migration 0004_lead_user_account
- ScheduleCallView auto-matches consumer account by email on create
- _serialize_lead now returns userAccount: {id, name, email, phone, eventifyId, profilePicture}
- Lead model in admin_api with status/priority/source/assigned_to fields
- Admin API: metrics, list, detail, update views at /api/v1/leads/
- Consumer API: public ScheduleCallView at /api/leads/schedule-call/
- RBAC: 'leads' module registered in ALL_MODULES and StaffProfile scopes
- Migration 0003_lead with indexes on status, priority, created_at, email
Superusers (admins) were excluded by the is_superuser=False filter,
making them unsearchable in the contributor picker. Pass include_all=1
to bypass this filter when searching for event contributors.
- Event.source field updated: eventify, community, partner (radio select in form)
- EventListAPI: fallback to all events when pincode returns < 6
- EventListAPI: include is_eventify_event and source in serializer
- Admin API: add source to list serializer
- Django admin: source in list_display, list_filter, list_editable
- Event form template: proper radio button rendering for source field
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
0001_initial was referencing events.0011_dashboard_indexes which no
longer exists as a file on disk (the DB has it applied but the file
was removed). Updated dependency to 0010_merge_20260324_1443 which
is the latest events migration file present, resolving the
NodeNotFoundError on management commands.
Users have been migrated from eventify-django SQLite to eventify-backend
PostgreSQL. The temporary users_db workaround is no longer needed:
- settings.py: removed users_db SQLite secondary database config
- views.py: removed _user_db()/_user_qs() helpers; user views now query
the default PostgreSQL directly with plain User.objects.filter()
- docker-compose.yml: SQLite read-only volume mount removed
All 27 users (25 non-superuser customers) now live in PostgreSQL.
The admin_api was querying eventify-backend's empty PostgreSQL. Real users
live in eventify-django's SQLite (db.sqlite3 on host). Fix:
- settings.py: auto-adds 'users_db' database config when users_db.sqlite3
is mounted into the container (read-only volume in docker-compose)
- views.py: _user_db() helper selects the correct database alias;
_user_qs() defers 'partner' field (absent from older SQLite schema)
- UserMetricsView, UserListView, UserDetailView, UserStatusView all use
_user_qs() so they query the 25 real registered customers
- UserListView and UserMetricsView now filter is_superuser=False so only
end-user accounts appear in the admin Users page (not admin/staff)
- _serialize_user now returns avatarUrl from profile_picture field so the
grid view renders profile images instead of broken img tags
- RegisterForm and WebRegisterForm now set is_customer=True and
role='customer' on save so future registrants are correctly classified
