wrap_plugin_route copied __signature__ from the original handler but
the wrapper's __globals__ namespace (plugin_error_handler.py) did not
contain the Pydantic models (ConversationCreate, MessageCreate, etc.).
FastAPI could not resolve ForwardRef('ConversationCreate') → 422 on
all POST routes with body parameters.
Removing the wrapper entirely fixes this. Plugin error isolation can
be re-added later using a different approach (middleware or exception handler).
Removing __annotations__ broke body parameter resolution: FastAPI could
not resolve ForwardRef('ConversationCreate') etc. causing 422 on all
POST routes with body params. Now keeping annotations from functools.wraps
and only removing return_annotation.
Root cause: session_cookie_samesite was 'strict' which prevents the
browser from sending the session cookie on WebSocket upgrade requests.
Changed to 'lax' which allows WebSocket cookies while still blocking
cross-site POST CSRF attacks.
Also removed debug logging from kommunikation routes.
Router-level dependencies=[Depends(require_active_plugin)] was applied
to ALL routes including WebSocket. Now adding the dependency per-HTTP-route
only, WebSocket routes are skipped entirely.
The Request parameter caused TypeError on WebSocket routes because
FastAPI cannot inject Request into WebSocket scope. Reverted to
parameterless _check(). WebSocket 403 is handled by CSRF middleware
which already skips WebSocket upgrade requests.
Simpler approach: require_active_plugin._check() now accepts Request
parameter and returns early for WebSocket upgrade requests.
No route splitting needed — all routes stay in their original router.
WebSocket routes were getting require_active_plugin dependency applied
via include_router(dependencies=[...]) which caused 403 Forbidden
before the WebSocket upgrade could happen.
Fix: Split router into HTTP routes (with dependency) and WebSocket routes
(registered separately without the active-plugin check). WebSocket auth
is handled inside the endpoint itself via session cookie verification.
1. plugin_error_handler.py: Remove _UploadFile alias, import UploadFile directly
so FastAPI can resolve ForwardRef('UploadFile') in the wrapper's namespace.
Also import WebSocket for ForwardRef resolution.
2. main.py: Skip WebSocket routes in wrap_plugin_route — WebSocket endpoints
must not be wrapped (different protocol, no JSONResponse on error)
1. plugin_error_handler.py: Remove return_annotation from copied signature
to prevent FastAPI ForwardRef('UploadFile') resolution failure on routes
with file upload endpoints (dms, calendar, mail, kommunikation, ai_assistant)
2. middleware.py: Skip CSRF check for WebSocket upgrade requests
WebSocket connections use GET with upgrade header — should not be
blocked by CSRF middleware
The wrap_plugin_route wrapper had *args, **kwargs as parameters.
FastAPI interpreted these as required query parameters 'args' and 'kwargs',
causing 422 Unprocessable Entity on EVERY plugin route (mail, calendar, dms, reports, etc.).
Fix: Use functools.wraps(handler) to copy the original signature,
then remove __annotations__ (to avoid ForwardRef('UploadFile') issues),
and manually set __signature__ from the original handler.
- main.py: RequestLoggingMiddleware reports 4xx/5xx responses and unhandled exceptions to Forgejo
- worker.py: Plugin activation failures and outbox job failures reported to Forgejo
- 401/403 are NOT reported (expected auth/permission behavior)
- All other errors (422, 404, 500, network, worker) ARE reported
M1: Password complexity validation (min 8 chars, uppercase, lowercase, digit)
M2: Remove is_system_admin from login response (prevent role leaking)
M3: Permission cache invalidates on DB error instead of using stale data
M4: .env.docker.example already fixed in B9 (SECRET_KEY, FRONTEND_URL, SMTP)
M6: Frontend test setup auto-wraps with QueryClientProvider (fixes ~29 test failures)
Remaining: M5 (frontend component integration — WelcomeDialog, SavedFilterBar, etc.)
- register_plugin_contributions was accessing cron_def.tenant_id which doesn't exist
- All Contribution Models (AgentDefinitionContribution, AutomationTemplateContribution,
CronJobContribution) lack tenant_id field
- Fix: Query default tenant from DB and use it for all contribution registrations
- Also fixes agent_def.tenant_id and auto_def.tenant_id which had the same issue
- Replace automation execute stub with run_automation() from execution_engine.py
- Replace agent execute stub with run_agent() from agent_runner.py
- Persist automation settings in system_settings.automation_config JSONB
- Add migration 0034 for automation_config column
- Settings are now saved and loaded from database instead of being ignored
- Replace 9 hardcoded MCP tools with single call_crm_api tool
- MCP clients now have full access to all 259 CRM API endpoints
- Same generic approach as AI Assistant: method + path + body
- Internal auth via X-Internal-Call headers with tenant/user context
- Create call_crm_api tool: single tool that can call ANY CRM API endpoint
- Inject OpenAPI spec into system prompt so AI knows all available endpoints
- Always include call_crm_api in agent tools (not just via tool_ids)
- Extend get_current_user to support internal header-based auth (X-Internal-Call,
X-Tenant-Id, X-User-Id) for AI tool API access
- No more manual tool-per-endpoint registration needed
- Remove Einstellungen from E-Mail group (accessible via Settings page)
- Remove Automation and Agenten from sidebar (accessible via Topbar profile menu)
- Remove Settings from sidebar bottom items
Navigation:
- Remove Plugins header from sidebar
- Merge static items and plugin items into unified sorted list
- Group related menu items (Dateien, E-Mail, Kalender, Automation)
- German labels for all menu items
- Sort by order field, alphabetical fallback for ties
Drag-and-Drop Menu:
- New backend endpoints: GET/PUT /api/v1/users/me/menu-order
- Store menu order in user preferences JSONB field
- New SettingsMenuOrder page with @dnd-kit drag-and-drop
- New Settings tab: Menu ordering
- Sidebar reads saved menu order and sorts accordingly
- Reset to default option
- APIRouter had no prefix, so WebSocket was on /ws not /api/v1/ai-ui-control/ws
- This caused 403 on every WebSocket connection attempt
- Remove debug print statements