User Management and Cleanup Guide

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Current User Status

​

User Statistics

​

User Breakdown by Type

​

User Sources

​

1. E2E Test Users

• e2e-auth-<timestamp>@test.com
• e2e-financial-<timestamp>@test.com
• e2e-leave-<timestamp>@test.com

​

2. RLS Test Users

• rls-scenario-testN-<timestamp>@example.com
• rls-close-testN-<timestamp>@example.com

​

3. Debug/Test Users

• admin-debug-<timestamp>@test.com
• regular-debug-<timestamp>@test.com
• test-user-a-fw-logs-<timestamp>@test.com

​

4. Seed Data Users

• admin@test-org-alpha.example
• manager@test-org-beta.example
• test.admin.N@orgN.staging.encoreos.io

​

5. Lovable Integration

• Auto-generates src/integrations/supabase/client.ts
• Auto-generates src/integrations/supabase/types.ts
• Manages .env file (when configured)
• Deploys edge functions automatically
• Does NOT create users directly

• Lovable does NOT create test users in the database
• Any users you see are from:
  • Automated test suites (E2E, RLS)
  • Manual testing/debugging
  • Seed data (staging only)
  • Real user signups

• Lovable may deploy to .lovable.app domains
• If you use Lovable deployment URLs, add them to Supabase redirect URLs
• See docs/development/SUPABASE_VERCEL_SETUP_FIX.md for configuration

​

User Cleanup Options

​

Option 1: Clean Up Test Users (Recommended - Use Script)

# Step 1: Dry-run to identify test users (no changes)
npm run db:cleanup:test-users -- --dry-run --env production

# Step 2: Preview what would be deleted
npm run db:cleanup:test-users -- --env production

# Step 3: Actually delete (requires --confirm flag)
npm run db:cleanup:test-users -- --env production --confirm

-- Identify test users (dry-run first)
SELECT id, email, created_at 
FROM auth.users
WHERE email LIKE '%test%' 
   OR email LIKE '%example%'
   OR email LIKE 'e2e-%'
   OR email LIKE 'rls-%'
   OR email LIKE '%debug%'
   OR email LIKE '%staging%'
ORDER BY created_at DESC;

-- Delete test users (CAREFUL - this is permanent!)
-- Only run after verifying the SELECT query above
DELETE FROM auth.users
WHERE email LIKE '%test%' 
   OR email LIKE '%example%'
   OR email LIKE 'e2e-%'
   OR email LIKE 'rls-%'
   OR email LIKE '%debug%'
   OR email LIKE '%staging%';

1. ✅ Verify you’re in the correct environment (production vs staging)
2. ✅ Run the SELECT query first to see what will be deleted
3. ✅ Consider backing up first
4. ✅ Check if any test users have important data

​

Option 2: Archive Test Users (Safer)

​

Alternative A: Use raw_user_meta_data JSONB

-- Mark test users as archived via metadata
UPDATE auth.users
SET raw_user_meta_data = raw_user_meta_data || '{"archived": true}'::jsonb
WHERE email LIKE '%test%' 
   OR email LIKE '%example%'
   OR email LIKE 'e2e-%'
   OR email LIKE 'rls-%'
   OR email LIKE '%debug%'
   OR email LIKE '%staging%';

-- Query to filter out archived users
SELECT * FROM auth.users 
WHERE (raw_user_meta_data->>'archived')::boolean IS NOT TRUE;

​

Alternative B: Use Application-Level Table (Recommended)

-- Create tracking table
CREATE TABLE IF NOT EXISTS pf_user_archive_status (
  user_id UUID PRIMARY KEY REFERENCES auth.users(id) ON DELETE CASCADE,
  archived BOOLEAN DEFAULT false,
  archived_at TIMESTAMPTZ,
  archived_by UUID REFERENCES auth.users(id),
  reason TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Enable RLS
ALTER TABLE pf_user_archive_status ENABLE ROW LEVEL SECURITY;

-- Allow platform admins to manage
CREATE POLICY "Platform admins manage archive status"
ON pf_user_archive_status
FOR ALL
USING (pf_has_system_role(auth.uid(), 'platform_admin'));

-- Archive test users
INSERT INTO pf_user_archive_status (user_id, archived, archived_at)
SELECT id, true, now()
FROM auth.users
WHERE email LIKE '%test%' 
   OR email LIKE '%example%'
   OR email LIKE 'e2e-%'
   OR email LIKE 'rls-%'
   OR email LIKE '%debug%'
   OR email LIKE '%staging%'
ON CONFLICT (user_id) DO UPDATE SET archived = true, archived_at = now();

-- Query non-archived users by joining
SELECT u.* FROM auth.users u
LEFT JOIN pf_user_archive_status a ON a.user_id = u.id
WHERE a.archived IS NOT TRUE OR a.user_id IS NULL;

​

Option 3: Clean Up by Date

-- Delete users created in last 7 days (if all are test users)
DELETE FROM auth.users
WHERE created_at > NOW() - INTERVAL '7 days'
  AND (email LIKE '%test%' OR email LIKE '%example%' OR email LIKE 'e2e-%' OR email LIKE 'rls-%');

​

Preventing Test User Accumulation

​

1. Use Test Isolation

• Use unique test user emails with timestamps
• Clean up test users after test runs
• Use test database or staging environment

• Use deterministic test user IDs
• Clean up after test suite completes
• Consider using test fixtures that clean up automatically

​

2. Environment Separation

• ✅ No test users should exist
• ✅ Only real user signups
• ✅ Regular cleanup of any accidental test users

• ✅ Test users are expected
• ✅ Seed data users are normal
• ✅ Can have test users for UAT

​

3. Automated Cleanup

# Clean up test users older than 30 days
# Run as scheduled job or manual cleanup

​

Lovable Integration Notes

​

Lovable Connection

• ✅ Supabase client configuration
• ✅ TypeScript types generation
• ✅ Environment variables (when configured)
• ✅ Edge function deployment
• ❌ Does NOT create users

​

Lovable Deployment URLs

1. Add to Supabase Redirect URLs:
   # In supabase/config.toml
   [remotes.production.auth]
   additional_redirect_urls = [
     # ... existing URLs ...
     "https://your-app.lovable.app/",
     "https://your-app.lovable.app/**",
   ]
   
2. Sync Config:
   supabase db push
   

​

Verification Queries

​

Check User Distribution

-- User types breakdown
SELECT 
  CASE 
    WHEN email LIKE 'e2e-%' THEN 'E2E Tests'
    WHEN email LIKE 'rls-%' THEN 'RLS Tests'
    WHEN email LIKE '%debug%' OR email LIKE '%test%' THEN 'Debug/Test'
    WHEN email LIKE '%example%' OR email LIKE '%staging%' THEN 'Seed Data'
    ELSE 'Production/Real'
  END as user_type,
  COUNT(*) as count
FROM auth.users
GROUP BY user_type
ORDER BY count DESC;

​

Check Recent User Creation

-- Users created in last 7 days
SELECT 
  DATE(created_at) as creation_date,
  COUNT(*) as users_created
FROM auth.users
WHERE created_at > NOW() - INTERVAL '7 days'
GROUP BY DATE(created_at)
ORDER BY creation_date DESC;

​

Find Test Users

-- All test users
SELECT id, email, created_at 
FROM auth.users
WHERE email LIKE '%test%' 
   OR email LIKE '%example%'
   OR email LIKE 'e2e-%'
   OR email LIKE 'rls-%'
   OR email LIKE '%debug%'
   OR email LIKE '%staging%'
ORDER BY created_at DESC;

​

Recommendations

​

For Production

1. Immediate: Review and clean up test users if they shouldn’t be there
2. Ongoing: Set up automated cleanup for test users
3. Monitoring: Add alerts for unexpected user creation spikes
4. Documentation: Document which users are legitimate

​

For Staging

1. Expected: Test users are normal in staging
2. Seed Data: Keep seed data users for UAT
3. Cleanup: Periodically clean up old test users (30+ days old)

​

For Development

1. Local: Use local Supabase instance for testing
2. Isolation: Use separate test databases when possible
3. Cleanup: Clean up test users after development sessions

​

Related Documentation

• Test User Cleanup Guide: docs/development/TEST_USER_CLEANUP_GUIDE.md - Complete cleanup procedures
• Setup Fix Guide: docs/development/SUPABASE_VERCEL_SETUP_FIX.md
• Testing Guide: docs/development/VERIFICATION_TESTING_GUIDE.md
• Lovable Integration: AGENTS.md
• Environment Config: ENVIRONMENT_CONFIG.md