cannamanage/docs/sprint-7/cannamanage-sprint7-analysis.md

# Sprint 7 Feature Analysis — Communication & Community

**Date:** 2026-06-13
**Author:** Patrick Plate / Lumen (Architect)
**Status:** Draft v1
**Sprint Goal:** Transform CannaManage from a compliance tool into a community platform — the communication layer that keeps members engaged and clubs organized.

---

## Executive Summary

Sprint 7 introduces four communication features that turn CannaManage from "backend compliance software" into a living club platform. The recommended Sprint 7 scope is:

1. **Club Info Board** (Schwarzes Brett) — ship it. Core feature, medium effort, high engagement value.
2. **Club-Internal Forum** — ship it (MVP). Threaded discussions within a club. High member engagement, competitive differentiator.
3. **Club-to-Member Notifications** (admin-composed) — ship it. Builds on existing Sprint 6 infrastructure. Low effort, high value.
4. **Cross-Club Community Forum** — defer to Sprint 8+. Legal complexity (KCanG), moderation overhead, and "nice to have" status make it wrong for this sprint.

**Strategic rationale:** No competitor (420cloud, Hanf-App, Cannanas) offers in-app community features. Clubs currently use Telegram/Signal/WhatsApp groups, which are unmoderated, unarchived, and disconnected from the platform. Owning the communication layer creates massive switching costs — once a club's discussions live in CannaManage, they can't leave without losing history.

---

## 1. Club Info Board (Schwarzes Brett)

### 1.1 Problem Statement

Club admins need a one-to-many broadcast channel: announcements, rule changes, event notices, operational updates ("We're closed next Thursday"), new strain arrivals. Today this happens in Telegram groups where messages get buried, new members miss old announcements, and there's no archive.

The Info Board is **not** a conversation — it's a pinboard. Staff posts, members read. Think: physical Schwarzes Brett in the club room, digitized.

### 1.2 How It Differs from Notifications

| Aspect | Notifications | Info Board |
|--------|--------------|-----------|
| Trigger | System-generated events (quota warning, batch recalled) | Human-authored by admin/staff |
| Persistence | Transient — read and dismiss | Permanent — archived, searchable |
| Visibility | Individual user inbox | All club members see all posts |
| Rich content | Short text + link | Rich text, images, attachments |
| Categories | NotificationType enum | Admin-defined categories |
| Interaction | Mark as read | Pin, archive, comment (optional) |

### 1.3 User Stories

| # | As a... | I want to... | So that... | Priority |
|---|---------|-------------|-----------|----------|
| IB-01 | Club Admin | Post an announcement with title, body, and category | All members see it on their dashboard | P0 |
| IB-02 | Club Admin | Pin an important post to the top | Critical info (rules, hours) stays visible | P0 |
| IB-03 | Club Admin | Attach images or PDFs to a post | I can share event flyers or updated rules docs | P1 |
| IB-04 | Club Admin | Archive old posts (not delete) | The board stays clean but history is preserved | P1 |
| IB-05 | Club Admin | Assign categories (Events, Rules, General, Strain News) | Members can filter what interests them | P1 |
| IB-06 | Staff (with permission) | Post announcements | The admin doesn't have to do everything | P0 |
| IB-07 | Member | See announcements on my portal dashboard | I don't miss important club news | P0 |
| IB-08 | Member | Filter posts by category | I only see what's relevant to me | P2 |
| IB-09 | Member | Get notified when a new post appears | I'm alerted even if I don't check the board | P1 |

### 1.4 Data Model

```sql
-- V11: Info Board
CREATE TABLE info_board_categories (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(100) NOT NULL,
    color VARCHAR(7),             -- hex color for UI badge
    sort_order INTEGER NOT NULL DEFAULT 0,
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE TABLE info_board_posts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    title VARCHAR(255) NOT NULL,
    body TEXT NOT NULL,            -- markdown or sanitized HTML
    category_id UUID REFERENCES info_board_categories(id),
    author_id UUID NOT NULL,      -- staff or admin user
    pinned BOOLEAN NOT NULL DEFAULT false,
    archived BOOLEAN NOT NULL DEFAULT false,
    published_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE TABLE info_board_attachments (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    post_id UUID NOT NULL REFERENCES info_board_posts(id) ON DELETE CASCADE,
    filename VARCHAR(255) NOT NULL,
    content_type VARCHAR(100) NOT NULL,
    size_bytes BIGINT NOT NULL,
    storage_path VARCHAR(500) NOT NULL,
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_info_board_posts_tenant ON info_board_posts(tenant_id, archived, pinned DESC, published_at DESC);
CREATE INDEX idx_info_board_posts_category ON info_board_posts(category_id);
```

**Key design decisions:**
- Markdown body (rendered on frontend) — simple, secure, no XSS risk from raw HTML
- `pinned` as boolean — pinned posts sort first, then by `published_at DESC`
- Soft-archive (not delete) — compliance friendliness, audit trail integrity
- Attachments stored on filesystem (or S3-compatible) — not in DB

### 1.5 UI Mockup Description

**Admin/Staff view (Dashboard → Info Board):**
- Top: "New Post" button (opens rich text editor)
- Category filter tabs (All | Events | Rules | General | Strain News)
- Post list: card layout with title, excerpt, author, date, pinned badge
- Each card: actions dropdown (Edit, Pin/Unpin, Archive)
- Attachment upload: drag-and-drop zone in the editor

**Portal/Member view (Portal Dashboard → Announcements section):**
- Latest 3-5 posts shown as cards on the portal dashboard
- "View All" link → dedicated announcements page
- Category color badges
- Pinned posts have a 📌 indicator and always show first
- Unread indicator (new posts since last visit)

### 1.6 Integration Points

| Integration | How |
|------------|-----|
| Notifications (existing) | New post → auto-generate `INFO_BOARD_POST` notification for all club members |
| WebSocket (existing) | Push new-post event in real-time to connected members |
| Audit Log (existing) | Log post creation, edits, archives as `INFO_BOARD_CREATED` / `INFO_BOARD_EDITED` / `INFO_BOARD_ARCHIVED` |
| StaffPermission | New permission: `MANAGE_INFO_BOARD` — controls who can post/edit/archive |

### 1.7 Plan Tier Mapping

| Tier | Info Board Access |
|------|------------------|
| Starter | ✅ Basic (3 categories max, no attachments) |
| Pro | ✅ Full (unlimited categories, attachments up to 10 MB) |
| Enterprise | ✅ Full + scheduled posts, auto-archive after N days |

---

## 2. Club-Internal Forum (Vereinsinterne Diskussion)

### 2.1 Problem Statement

Members want to talk to each other — not just passively receive announcements. Today they use Telegram/WhatsApp groups that are:
- Unmoderated (spam, off-topic, conflicts)
- Ephemeral (messages get buried, no searchable archive)
- Disconnected from the club platform (no link to member profiles, no awareness of club context)
- A privacy leak (phone numbers exposed to all members)

A club-internal forum gives members a place to discuss within the platform — moderated, archived, searchable, and integrated with member identity.

### 2.2 How It Differs from Info Board

| Aspect | Info Board | Forum |
|--------|-----------|-------|
| Direction | One-to-many (staff → members) | Many-to-many (members ↔ members) |
| Who posts | Admin/Staff only | All members |
| Structure | Flat list of posts | Threaded: Topics → Replies |
| Moderation | N/A (staff controls everything) | Staff can moderate, lock, delete |
| Purpose | Official communication | Community discussion |

### 2.3 User Stories

| # | As a... | I want to... | So that... | Priority |
|---|---------|-------------|-----------|----------|
| FO-01 | Member | Create a new discussion topic | I can ask questions or start conversations | P0 |
| FO-02 | Member | Reply to an existing topic | I can participate in discussions | P0 |
| FO-03 | Member | Browse topics by category | I find relevant discussions | P0 |
| FO-04 | Member | See who posted (display name + avatar) | I know who I'm talking to | P0 |
| FO-05 | Member | Edit my own posts (within 30 min) | I can fix typos | P1 |
| FO-06 | Member | Report inappropriate posts | I can flag content for moderators | P1 |
| FO-07 | Staff/Admin | Create and manage forum categories | Discussions are organized | P0 |
| FO-08 | Staff/Admin | Delete posts / lock topics | I can moderate inappropriate content | P0 |
| FO-09 | Staff/Admin | Pin important topics | Key discussions stay visible | P1 |
| FO-10 | Staff/Admin | See reported posts in a moderation queue | I can act on reports efficiently | P1 |
| FO-11 | Member | Get notified when someone replies to my topic | I don't miss responses | P1 |
| FO-12 | Member | Upload images in posts | I can share photos (grow results, events) | P2 |
| FO-13 | Member | React to posts (thumbs up, leaf emoji) | I can show appreciation without cluttering | P2 |

### 2.4 Data Model

```sql
-- V12: Club-Internal Forum
CREATE TABLE forum_categories (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(100) NOT NULL,
    description VARCHAR(500),
    icon VARCHAR(50),             -- emoji or icon name
    sort_order INTEGER NOT NULL DEFAULT 0,
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE TABLE forum_topics (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    title VARCHAR(255) NOT NULL,
    body TEXT NOT NULL,            -- first post content (markdown)
    category_id UUID NOT NULL REFERENCES forum_categories(id),
    author_id UUID NOT NULL,      -- member or staff user
    pinned BOOLEAN NOT NULL DEFAULT false,
    locked BOOLEAN NOT NULL DEFAULT false,
    reply_count INTEGER NOT NULL DEFAULT 0,
    last_reply_at TIMESTAMP WITH TIME ZONE,
    last_reply_by UUID,
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE TABLE forum_replies (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    topic_id UUID NOT NULL REFERENCES forum_topics(id) ON DELETE CASCADE,
    body TEXT NOT NULL,            -- markdown
    author_id UUID NOT NULL,
    edited_at TIMESTAMP WITH TIME ZONE,
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE TABLE forum_reports (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    reporter_id UUID NOT NULL,
    target_type VARCHAR(10) NOT NULL,  -- 'TOPIC' or 'REPLY'
    target_id UUID NOT NULL,
    reason VARCHAR(500) NOT NULL,
    resolved BOOLEAN NOT NULL DEFAULT false,
    resolved_by UUID,
    resolved_at TIMESTAMP WITH TIME ZONE,
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE TABLE forum_reactions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL,
    target_type VARCHAR(10) NOT NULL,  -- 'TOPIC' or 'REPLY'
    target_id UUID NOT NULL,
    reaction VARCHAR(20) NOT NULL,    -- 'thumbsup', 'leaf', 'fire', 'heart'
    tenant_id UUID NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    UNIQUE(user_id, target_type, target_id, reaction)
);

CREATE INDEX idx_forum_topics_tenant ON forum_topics(tenant_id, category_id, pinned DESC, last_reply_at DESC);
CREATE INDEX idx_forum_replies_topic ON forum_replies(topic_id, created_at);
CREATE INDEX idx_forum_reports_unresolved ON forum_reports(tenant_id, resolved, created_at);
```

**Key design decisions:**
- Flat replies (not nested/threaded) — simpler UX, easier to follow, works on mobile
- `reply_count` + `last_reply_at` denormalized on topics — avoids expensive JOINs for listing
- Edit window: 30 minutes (set in application logic, not DB)
- Reactions: limited set (4-5 emojis) — not free-form to keep it simple
- Reports go to a moderation queue — staff sees flagged content

### 2.5 Moderation Features

| Feature | How It Works |
|---------|-------------|
| Delete post/reply | Staff removes content, replaced with "[Beitrag entfernt]" placeholder |
| Lock topic | No new replies allowed. Existing content preserved. |
| Pin topic | Pinned topics always appear at the top of category view |
| Report queue | Members flag → staff sees queue → resolve (delete, warn, or dismiss) |
| Auto-lock inactive | Topics with no replies for 90 days auto-lock (configurable) |
| Word filter | Optional blocklist (admin-configured) — posts with blocked words held for review |

**New StaffPermission:** `MODERATE_FORUM` — controls access to moderation queue and lock/delete actions.

### 2.6 UI Mockup Description

**Forum main page (Dashboard → Forum):**
- Category cards with name, description, topic count, last activity
- "New Topic" button (per category or global)
- Search bar (full-text search across topics and replies)

**Category view:**
- Topic list: title, author, reply count, last reply date
- Pinned topics at top with badge
- Locked topics with lock icon
- Pagination (20 topics per page)

**Topic view:**
- Original post at top
- Replies below in chronological order
- Reply editor at bottom (markdown with preview)
- Reaction buttons on each post
- "Report" link on each post (subtle, doesn't clutter)
- Lock/Delete/Pin controls for staff (contextual)

**Portal/Member view:**
- Same forum, just within the portal layout
- Members see their own posts highlighted
- "My Topics" and "Subscribed" quick filters

### 2.7 Plan Tier Mapping

| Tier | Forum Access |
|------|-------------|
| Starter | ❌ Not included (upgrade incentive) |
| Pro | ✅ Full forum (5 categories max) |
| Enterprise | ✅ Full forum (unlimited categories, custom word filter, advanced moderation) |

---

## 3. Cross-Club Community Forum

### 3.1 Problem Statement

Members from different clubs may want to exchange knowledge — growing tips, legal questions, strain reviews, event coordination. Currently there's no platform-level community; people use Reddit, Telegram, or CannaConnection forums.

A cross-club forum would make CannaManage a "social network for CSC members" — a powerful retention mechanism. But it also introduces significant complexity: moderation at scale, privacy concerns, and legal implications under KCanG.

### 3.2 User Stories

| # | As a... | I want to... | So that... | Priority |
|---|---------|-------------|-----------|----------|
| CC-01 | Member | Browse community topics from all clubs | I can learn from other clubs' experiences | P1 |
| CC-02 | Member | Post in the community forum | I can share knowledge with the wider community | P1 |
| CC-03 | Member | Choose to appear as "Member of [ClubName]" or anonymous | I control my privacy | P0 |
| CC-04 | Platform Admin | Moderate cross-club content | The community stays safe and legal | P0 |
| CC-05 | Platform Admin | Define community-wide categories | Content is organized | P0 |
| CC-06 | Club Admin | Opt their club in/out of community features | They control member exposure | P1 |

### 3.3 Data Model (Multi-Tenant Considerations)

The cross-club forum breaks the fundamental `tenant_id` isolation pattern. Every other entity in CannaManage is scoped to a single club. A cross-club entity needs either:

**Option A: Separate schema (no tenant_id)**
```sql
-- community_topics, community_replies — NOT extending AbstractTenantEntity
-- Use a separate 'platform_user_id' that maps to the user across clubs
```

**Option B: Platform-level tenant (tenant_id = NULL or platform UUID)**
```sql
-- A special "platform" tenant that all users can access
-- More complex query logic: WHERE tenant_id = :current OR tenant_id = :platform
```

**Recommendation:** Option A — separate schema. The cross-club forum is architecturally a different bounded context. Mixing it with tenant-scoped entities creates query complexity and potential data leakage bugs.

### 3.4 Legal & Privacy Analysis (KCanG Implications)

| Concern | Analysis | Risk Level |
|---------|----------|-----------|
| **KCanG §4 — Advertising prohibition** | CSCs may not advertise cannabis or their club publicly. A cross-club forum where clubs share their strains could be interpreted as advertising. | 🟡 Medium |
| **KCanG §18 — Data handling** | Member data must be handled with care. Cross-club exposure of member names (even display names) to non-club-members may violate the principle of data minimization. | 🟡 Medium |
| **DSGVO Art. 5(1)(c) — Data minimization** | Exposing member identity across clubs goes beyond what's necessary for club management. Must offer genuine anonymity option. | 🔴 High |
| **KCanG §5 — Membership restriction** | Members can only belong to one CSC. If the forum reveals multi-club participation, it could expose legal violations. | 🟡 Medium |
| **Platform liability** | If the platform hosts inter-club communication, it becomes a publisher/moderator of cannabis-related content. Illegal content (sales, purchases) is a risk. | 🔴 High |
| **Age verification** | KCanG requires age verification for membership. A community forum accessible to "all members" must ensure all participants are verified. | 🟢 Low (all members already verified) |

**Legal recommendation:** If built, the cross-club forum MUST:
1. Default to anonymous posting (no club name, no real name)
2. Prohibit any form of transaction/trade discussion
3. Include clear terms of use that forbid advertising
4. Have active platform-level moderation
5. Allow clubs to opt-out entirely
6. Allow individual members to opt-out

### 3.5 Moderation at Platform Level

| Challenge | Solution |
|-----------|----------|
| Scale | Platform admin team or community moderators (elevated non-admin users) |
| Illegal content | Automated keyword filtering + user reports + manual review |
| Cross-club disputes | Platform terms of service, not individual club rules |
| Reporting to authorities | If illegal activity is detected, platform has Mitwirkungspflicht |
| Content liability | Clear Terms of Service, notice-and-takedown procedure |

### 3.6 Recommendation: Defer to Sprint 8+

**Reasons to defer:**
1. **Legal complexity** — needs actual legal review (not just developer analysis)
2. **Architectural break** — violates the clean tenant isolation model; needs careful design
3. **Moderation overhead** — requires platform-level moderation tooling that doesn't exist yet
4. **Low priority** — club-internal communication is far more valuable than inter-club
5. **Competitive non-urgency** — no competitor has this either; no market pressure
6. **MVP path** — clubs can still use Telegram for inter-club chat; CannaManage solves the intra-club problem first

**When to revisit:** After 50+ clubs are on the platform and actively request it. Validate demand before building.

### 3.7 Plan Tier Mapping (if eventually built)

| Tier | Community Forum |
|------|----------------|
| Starter | ❌ Not included |
| Pro | ✅ Read-only access |
| Enterprise | ✅ Full access (post + moderate) |

---

## 4. Club Notifications to Members (Benachrichtigungen)

### 4.1 Existing Infrastructure (What We Already Have)

Sprint 6 delivered a solid notification foundation:

| Component | Status | Details |
|-----------|--------|---------|
| `notifications` table | ✅ Built | UUID PK, user_id, type, title, message, link, read flag, tenant_id |
| `Notification` entity | ✅ Built | JPA entity extending `AbstractTenantEntity` |
| `NotificationType` enum | ✅ Built | 4 system types: `QUOTA_WARNING`, `BATCH_RECALLED`, `DISTRIBUTION_RECORDED`, `SUBSCRIPTION_EXPIRING` |
| REST API (`/notifications`) | ✅ Built | GET list, PUT mark-read, PUT mark-all-read |
| Frontend service | ✅ Built | `getNotifications()`, `markNotificationAsRead()`, `markAllNotificationsAsRead()` |
| WebSocket (SockJS/STOMP) | ✅ Built | Real-time push to connected clients (Nginx configured for `/ws/` upgrade) |
| PWA + Service Worker | ✅ Built | Manifest, offline page, install prompt (Sprint 6 Phase 6) |
| Bell icon in nav | ✅ Built | Unread count badge in dashboard header |

**What works today:** System-generated notifications (triggered by backend events) get stored in the DB, pushed via WebSocket to the frontend, and shown in the bell dropdown. Members can mark them as read.

### 4.2 Gap Analysis (What's Missing)

| Gap | Description | Effort |
|-----|------------|--------|
| **Admin compose UI** | No interface for admins to write and send custom notifications | Medium |
| **Targeting** | Current notifications are individual (`user_id`). No way to send to "all members" or "members in group X" | Medium |
| **Custom notification types** | Only 4 system types. Need `ADMIN_MESSAGE`, `INFO_BOARD_POST`, `FORUM_REPLY` | Low |
| **Email delivery channel** | Notifications are in-app only. No email fallback for offline users | Medium |
| **Push notifications (Web Push API)** | PWA exists but Web Push subscription/delivery not implemented | Medium |
| **Scheduling** | Can't schedule a notification for future delivery | Low |
| **Templates** | No template system for recurring notifications | Low |
| **Read receipts** | Admin can't see who read the notification | Low |
| **Member groups/segments** | No concept of member groups for targeted sending | Medium |

### 4.3 User Stories

| # | As a... | I want to... | So that... | Priority |
|---|---------|-------------|-----------|----------|
| NT-01 | Club Admin | Compose a custom notification with title + message | I can reach members directly | P0 |
| NT-02 | Club Admin | Send to all members at once | I don't have to select each one individually | P0 |
| NT-03 | Club Admin | Send to specific members (multi-select) | I can target a subset | P1 |
| NT-04 | Club Admin | Preview before sending | I catch mistakes before broadcasting | P0 |
| NT-05 | Club Admin | See delivery stats (sent/read counts) | I know if members are getting the message | P1 |
| NT-06 | Member | Receive notifications in-app (real-time) | I see messages immediately when online | P0 |
| NT-07 | Member | Receive email for important notifications (opt-in) | I don't miss things when offline | P1 |
| NT-08 | Member | Control which notification types I receive | I'm not overwhelmed | P2 |
| NT-09 | Club Admin | Schedule a notification for later | I can prepare communications in advance | P2 |

### 4.4 Admin UI for Composing Notifications

**Page: Dashboard → Notifications → Compose**

```
┌─────────────────────────────────────────────────┐
│  📣 Neue Benachrichtigung                        │
├─────────────────────────────────────────────────┤
│                                                 │
│  Empfänger: [● Alle Mitglieder ▼]              │
│             ○ Ausgewählte Mitglieder            │
│             [Search + multi-select chips]        │
│                                                 │
│  Titel:    [____________________________]       │
│                                                 │
│  Nachricht:                                     │
│  ┌─────────────────────────────────────────┐   │
│  │ (Markdown editor with preview toggle)    │   │
│  │                                          │   │
│  └─────────────────────────────────────────┘   │
│                                                 │
│  Link (optional): [________________________]    │
│                                                 │
│  □ Auch per E-Mail senden                       │
│                                                 │
│  [Vorschau]              [Senden]               │
│                                                 │
└─────────────────────────────────────────────────┘
```

**Notification History page:**
- Table of sent notifications with: title, recipients (count), sent date, read rate
- Click to see per-recipient read status
- Resend option for unread recipients

### 4.5 Delivery Channels

| Channel | Implementation | Priority |
|---------|---------------|----------|
| **In-app (WebSocket)** | Already works. Extend to handle `ADMIN_MESSAGE` type. | P0 (exists) |
| **In-app (polling fallback)** | Already works via REST GET `/notifications`. | P0 (exists) |
| **Email** | Use existing `EmailService`. New template: `notification-email.txt`. Opt-in per member. | P1 |
| **Web Push** | Register subscription via Push API. Backend stores endpoint + keys. Send via `web-push` library. | P2 (Sprint 8) |

### 4.6 Targeting (All, Groups, Individuals)

**Phase 1 (Sprint 7):**
- Send to ALL members (broadcast)
- Send to selected individuals (multi-select picker)

**Phase 2 (Sprint 8+):**
- Member groups/segments (e.g., "Board Members", "Active Growers", "New Members < 30 days")
- Tag-based targeting
- Dynamic segments (members who haven't visited in 30 days)

### 4.7 Data Model Changes

```sql
-- Extend NotificationType enum (code change only, no migration needed)
-- Add: ADMIN_MESSAGE, INFO_BOARD_POST, FORUM_REPLY, FORUM_MENTION

-- V13: Notification send log (for admin-composed notifications)
CREATE TABLE notification_sends (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    title VARCHAR(255) NOT NULL,
    message TEXT NOT NULL,
    link VARCHAR(500),
    author_id UUID NOT NULL,
    target_type VARCHAR(20) NOT NULL,  -- 'ALL', 'SELECTED'
    target_count INTEGER NOT NULL,
    read_count INTEGER NOT NULL DEFAULT 0,
    sent_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    tenant_id UUID NOT NULL
);

CREATE TABLE notification_send_recipients (
    send_id UUID NOT NULL REFERENCES notification_sends(id) ON DELETE CASCADE,
    user_id UUID NOT NULL,
    notification_id UUID REFERENCES notifications(id),  -- links to the actual notification created
    PRIMARY KEY (send_id, user_id)
);

CREATE INDEX idx_notification_sends_tenant ON notification_sends(tenant_id, sent_at DESC);
```

---

## 5. Prioritization & Sprint Plan

### 5.1 Feature Priority Matrix

| Feature | User Value | Competitive Edge | Build Effort | Risk | Sprint 7? |
|---------|-----------|-----------------|-------------|------|-----------|
| Club Notifications (admin compose) | 🟢 High | 🟢 Medium | 🟢 Low (builds on existing) | 🟢 Low | ✅ Yes |
| Club Info Board | 🟢 High | 🟢 High (no competitor has it) | 🟡 Medium | 🟢 Low | ✅ Yes |
| Club-Internal Forum | 🟢 High | 🟢 High (no competitor has it) | 🟡 Medium-High | 🟡 Medium (moderation) | ✅ Yes (MVP) |
| Cross-Club Forum | 🟡 Medium | 🟡 Medium | 🔴 High | 🔴 High (legal, arch) | ❌ Defer |

### 5.2 Recommended Sprint 7 Scope

```
Phase 1: Admin Notifications (builds on existing infra)
Phase 2: Info Board (Schwarzes Brett)
Phase 3: Forum MVP (categories, topics, replies, basic moderation)
Phase 4: Integration (notifications ↔ info board ↔ forum)
Phase 5: Polish & testing
```

#### Phase 1 — Admin Notifications

| Step | Description |
|------|-------------|
| 1.1 | Extend `NotificationType` enum: `ADMIN_MESSAGE`, `INFO_BOARD_POST`, `FORUM_REPLY` |
| 1.2 | Add `notification_sends` table (Flyway V13) |
| 1.3 | Backend: `NotificationComposeService` — create notification for multiple recipients |
| 1.4 | Backend: `POST /api/v1/notifications/compose` endpoint |
| 1.5 | Frontend: Compose notification page (admin area) |
| 1.6 | Frontend: Notification history page with read stats |
| 1.7 | Email delivery: notification email template + opt-in flag on member |
| 1.8 | New `StaffPermission`: `SEND_NOTIFICATIONS` |

#### Phase 2 — Info Board

| Step | Description |
|------|-------------|
| 2.1 | `info_board_categories` + `info_board_posts` + `info_board_attachments` tables (Flyway V14) |
| 2.2 | Backend: `InfoBoardService` — CRUD for categories and posts |
| 2.3 | Backend: REST endpoints `POST/GET/PUT /api/v1/info-board/posts`, `GET /api/v1/info-board/categories` |
| 2.4 | Backend: File upload endpoint for attachments |
| 2.5 | Frontend (admin): Info Board management page (create, edit, pin, archive) |
| 2.6 | Frontend (portal): Announcements section on member dashboard + dedicated page |
| 2.7 | Integration: New post → auto-notify all members (uses Phase 1 infra) |
| 2.8 | New `StaffPermission`: `MANAGE_INFO_BOARD` |

#### Phase 3 — Forum MVP

| Step | Description |
|------|-------------|
| 3.1 | Forum tables (Flyway V15): categories, topics, replies, reports, reactions |
| 3.2 | Backend: `ForumService` — topics CRUD, replies CRUD, moderation actions |
| 3.3 | Backend: REST endpoints for forum (topics, replies, categories, reports) |
| 3.4 | Frontend: Forum page (category list → topic list → topic detail with replies) |
| 3.5 | Frontend: New topic / reply editors (markdown) |
| 3.6 | Frontend: Moderation panel (report queue, lock/delete actions) |
| 3.7 | Integration: Reply notification → auto-notify topic author |
| 3.8 | New `StaffPermission`: `MODERATE_FORUM` |

#### Phase 4 — Integration & Polish

| Step | Description |
|------|-------------|
| 4.1 | WebSocket events for new info board posts and forum replies |
| 4.2 | Audit log events for info board and forum actions |
| 4.3 | Portal navigation update (add Forum, Announcements) |
| 4.4 | Dashboard widget: "Latest Announcements" + "Recent Forum Activity" |
| 4.5 | Email notifications for forum replies (opt-in) |

#### Phase 5 — Testing

| Step | Description |
|------|-------------|
| 5.1 | Unit tests for all new services |
| 5.2 | Integration tests for forum + info board + notifications |
| 5.3 | E2E tests (Playwright): post announcement, create topic, reply |
| 5.4 | Tenant isolation verification (no cross-club data leaks) |
| 5.5 | Permission checks (unauthorized staff can't post/moderate) |

### 5.3 Deferred to Sprint 8+

| Feature | Reason | When |
|---------|--------|------|
| Cross-Club Community Forum | Legal review needed, architecture break | Sprint 9+ (if validated) |
| Web Push Notifications | PWA push subscription, VAPID keys | Sprint 8 |
| Member groups / segments | Low urgency, "all members" is sufficient for MVP | Sprint 8 |
| Scheduled notifications | Nice-to-have, not blocking | Sprint 8 |
| Forum image uploads | Moderation complexity, storage cost | Sprint 8 |
| Forum search (full-text) | PostgreSQL FTS setup, medium effort | Sprint 8 |
| Notification preferences (per-type opt-in/out) | UX complexity | Sprint 8 |
| Rich text editor (WYSIWYG vs markdown) | Markdown is sufficient for MVP | Sprint 9 |

### 5.4 Dependencies Between Features

```mermaid
graph TD
    A[Phase 1: Admin Notifications] --> B[Phase 2: Info Board]
    A --> C[Phase 3: Forum MVP]
    B --> D[Phase 4: Integration]
    C --> D
    D --> E[Phase 5: Testing]
    
    subgraph Existing Infrastructure
        N[Notification entity + table]
        W[WebSocket STOMP]
        P[StaffPermission system]
        AU[AuditService]
    end
    
    N --> A
    W --> A
    P --> A
    P --> B
    P --> C
    AU --> D
```

**Critical path:** Phase 1 must come first because Phases 2 and 3 depend on it for their notification integration.

---

## 6. Technical Architecture

### 6.1 New Entities & Migrations

| Migration | Tables | Entity Classes |
|-----------|--------|---------------|
| V11 | `info_board_categories`, `info_board_posts`, `info_board_attachments` | `InfoBoardCategory`, `InfoBoardPost`, `InfoBoardAttachment` |
| V12 | `forum_categories`, `forum_topics`, `forum_replies`, `forum_reports`, `forum_reactions` | `ForumCategory`, `ForumTopic`, `ForumReply`, `ForumReport`, `ForumReaction` |
| V13 | `notification_sends`, `notification_send_recipients` | `NotificationSend`, `NotificationSendRecipient` |

**All new entities extend `AbstractTenantEntity`** — tenant isolation by default.

### 6.2 API Endpoints

```
# Admin Notifications
POST   /api/v1/notifications/compose        — Send notification to targets
GET    /api/v1/notifications/sends           — List sent notifications (admin)
GET    /api/v1/notifications/sends/{id}      — Get send details + per-recipient status

# Info Board
GET    /api/v1/info-board/categories         — List categories
POST   /api/v1/info-board/categories         — Create category (admin)
PUT    /api/v1/info-board/categories/{id}    — Update category (admin)
GET    /api/v1/info-board/posts              — List posts (paginated, filterable)
POST   /api/v1/info-board/posts              — Create post (staff with permission)
PUT    /api/v1/info-board/posts/{id}         — Update post
PUT    /api/v1/info-board/posts/{id}/pin     — Toggle pin
PUT    /api/v1/info-board/posts/{id}/archive — Archive post
POST   /api/v1/info-board/posts/{id}/attachments — Upload attachment
GET    /api/v1/info-board/posts/{id}/attachments/{aid} — Download attachment

# Forum
GET    /api/v1/forum/categories              — List forum categories
POST   /api/v1/forum/categories              — Create category (admin)
GET    /api/v1/forum/topics                  — List topics (paginated, by category)
POST   /api/v1/forum/topics                  — Create topic (any member)
GET    /api/v1/forum/topics/{id}             — Get topic with replies (paginated)
PUT    /api/v1/forum/topics/{id}             — Edit topic (author, within 30 min)
PUT    /api/v1/forum/topics/{id}/pin         — Pin topic (moderator)
PUT    /api/v1/forum/topics/{id}/lock        — Lock topic (moderator)
DELETE /api/v1/forum/topics/{id}             — Delete topic (moderator)
POST   /api/v1/forum/topics/{id}/replies     — Post reply (any member)
PUT    /api/v1/forum/replies/{id}            — Edit reply (author, within 30 min)
DELETE /api/v1/forum/replies/{id}            — Delete reply (moderator)
POST   /api/v1/forum/reports                 — Report a post/reply
GET    /api/v1/forum/reports                 — List reports (moderator)
PUT    /api/v1/forum/reports/{id}/resolve    — Resolve report (moderator)
POST   /api/v1/forum/reactions               — Add reaction
DELETE /api/v1/forum/reactions/{id}          — Remove reaction
```

### 6.3 Frontend Pages/Components

**Admin Dashboard additions:**
- `/settings/info-board` — Info Board management (categories + post editor)
- `/settings/notifications/compose` — Compose notification
- `/settings/notifications/history` — Sent notifications log
- `/forum` — Forum with admin moderation controls

**Portal additions:**
- `/portal/announcements` — All info board posts
- `/portal/forum` — Forum access for members
- Portal dashboard: "Announcements" widget + "Forum Activity" widget

**Shared components:**
- `MarkdownEditor` — textarea with preview toggle (reusable for info board + forum)
- `CategoryBadge` — colored badge component
- `ReactionBar` — reaction emoji buttons with counts
- `ModerationActions` — dropdown with delete/lock/pin (shown to staff)

### 6.4 WebSocket Integration

Extend the existing STOMP broker with new message types:

```
/topic/club/{tenantId}/notifications  — existing (extend with new types)
/topic/club/{tenantId}/info-board     — new post published
/topic/club/{tenantId}/forum          — new topic or reply in subscribed topic
```

**Frontend subscription (React hook):**
```typescript
// useForumSubscription(topicId) → real-time new replies
// useInfoBoardSubscription() → real-time new posts  
// useNotificationSubscription() → existing, extended with ADMIN_MESSAGE
```

### 6.5 Search & Performance Considerations

| Concern | Solution |
|---------|----------|
| Forum topic listing performance | Denormalized `reply_count` + `last_reply_at` on topic table. Paginate at 20 per page. |
| Info board post search | PostgreSQL `ILIKE` on title + body for MVP. Full-text search (tsvector) in Sprint 8 if needed. |
| Notification fan-out (send to 500 members) | Batch INSERT using `JdbcTemplate.batchUpdate()`. Don't create 500 individual transactions. |
| WebSocket scaling | Single server is fine for MVP (< 1000 concurrent connections). Redis pub/sub for horizontal scaling if needed later. |
| Attachment storage | Local filesystem for MVP (`/data/attachments/{tenant_id}/{post_id}/`). S3-compatible object storage for production scale. |
| Forum reaction counting | `COUNT(*)` with GROUP BY on reactions table. Cache in application if >1000 reactions per post (unlikely in Sprint 7). |

---

## 7. New StaffPermissions Summary

```java
public enum StaffPermission {
    RECORD_DISTRIBUTION,
    VIEW_MEMBER_LIST,
    VIEW_MEMBER_QUOTA,
    ADD_MEMBER,
    VIEW_STOCK,
    RECORD_STOCK_IN,
    VIEW_COMPLIANCE_REPORT,
    MANAGE_GROW_CALENDAR,
    // Sprint 7 additions:
    SEND_NOTIFICATIONS,      // Compose + send admin notifications
    MANAGE_INFO_BOARD,       // Create/edit/pin/archive info board posts
    MODERATE_FORUM           // Delete posts, lock topics, resolve reports
}
```

---

## 8. GDPR/KCanG Compliance Checklist

| Requirement | How We Address It |
|-------------|------------------|
| DSGVO Art. 5 — Data minimization | Forum posts only show display name (never real name or email). No data shared cross-club. |
| DSGVO Art. 17 — Right to erasure | Member deletion cascades to their forum posts (anonymized, not removed: "Ehemaliges Mitglied") |
| DSGVO Art. 15 — Data export | Export includes forum posts and info board interactions in data package |
| KCanG §4 — No advertising | Forum rules explicitly prohibit strain advertising. Moderation enforces this. |
| KCanG §18 — Data handling | All communication data scoped to tenant_id. No cross-club exposure. Club admin controls who can participate. |
| Audit compliance | Info board posts and moderation actions logged in immutable audit trail |

---

## 9. Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|------------|--------|-----------|
| Moderation burden overwhelms club admins | Medium | Medium | Start with simple report queue. Auto-lock inactive topics. Word filter optional. |
| Low member engagement with forum | Medium | Low | Info Board is one-way (guaranteed content). Forum is additive. Don't over-invest. |
| Markdown too technical for non-technical admins | Low | Medium | Provide a toolbar (bold/italic/link buttons) over the textarea. Add preview. |
| Attachment storage fills disk | Low | Medium | Set max file size (10 MB). Set per-club storage quota (100 MB Starter, 1 GB Pro). |
| Notification spam (admin sends too often) | Low | Medium | Show "last sent" timestamp. Optional daily digest mode in Sprint 8. |
| Tenant isolation bug (cross-club data leak) | Low | 🔴 Critical | Integration test specifically for tenant isolation on all new entities. AbstractTenantEntity pattern prevents most issues. |

---

## 10. Success Metrics

| Metric | Target (3 months post-launch) | How to Measure |
|--------|------------------------------|---------------|
| Info Board posts created | 5+ per club per month | Count `info_board_posts` per tenant per month |
| Forum topics created | 10+ per club per month | Count `forum_topics` per tenant per month |
| Admin notifications sent | 3+ per club per month | Count `notification_sends` per tenant per month |
| Member forum participation rate | >30% of members posted at least once | Distinct `author_id` / total members |
| Notification read rate | >70% within 48 hours | `read_count / target_count` on notification_sends |
| Moderation queue response time | <24 hours | Time between report creation and resolution |