🏗️ Architecture: How should email communication management and role-based cha...

Date: 2026-03-21
Time: 18:09:41 UTC
Session: gspace1-250.11
Agent: angular
Confidence: 88%
Status: ✅ Documented

📋 Decision Context

Question:

How should email communication management and role-based channel filtering be architected across gograb-admin, gograb-dev, and gograb-space?

Task: S250: Email lib + role-based channel UX architecture

🎯 Decision Made

Chosen:

Three changes: (1) Do NOT create a new NX lib for email — extend the existing ChannelManagerComponent with email SMTP validation and a test-send capability, matching the pattern just established for Slack/Discord/Telegram. A separate email lib would be premature — the existing channel manager already handles email setup, it just needs the validation gap closed. (2) Add role-based channel visibility to ChannelManagerComponent using the existing PlatformRole system — executive/developer sees all channels + admin tools (webhook, API config), admin sees standard channels, builder/user sees only channels relevant to their space. Use the existing chatFeaturesForPlatformRole pattern (derivePermissions → feature flags). (3) Email provider presets (Gmail, Outlook, Custom) to eliminate SMTP expertise requirement for non-technical users.

Options Considered:

1. New libs/libs-ui/email-communications lib (fragments management surface, premature)
2. Extend ChannelManagerComponent with role filtering + email validation (chosen — minimal, follows existing patterns)
3. New libs/libs-structural/channel-management lib that replaces ChannelManager (over-engineered rewrite)

💭 Reasoning

Research revealed: (a) EmailService backend exists and works (SendGrid). (b) ChannelManagerComponent already has the email setup form with 5 SMTP fields. (c) The gap is validation (no SMTP test endpoint) and UX (assumes SMTP expertise). (d) Role-based access already has infrastructure — PlatformRole type, derivePermissions(), chatFeaturesForPlatformRole() — but ChannelManagerComponent doesn't use it. (e) Creating a separate email-communications lib would fragment the channel management surface — all channels should be managed in one place, filtered by role. The existing pattern is 'same component, different platformRole input' which works well. What's missing is: the component doesn't READ the role to filter which channels are shown. Adding a channelVisibility computed based on platformRole is the minimal change. Email provider presets (Gmail preset fills smtp.gmail.com:587 automatically) reduce the SMTP expertise barrier dramatically.

📁 Files Involved

• libs/libs-ai/vitto-hub/src/lib/components/channel-manager/channel-manager.component.ts
• libs/libs-foundational/core-models/src/lib/utils/role-derivation.ts
• libs/libs-api/messaging-core/src/lib/services/email.service.ts
• APIs/backend-vitto-api/src/app/engine/vitto.controller.ts

🔗 Related

• Decision ID: dev_1774116581368_0y51hn4
• Session: 250
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation