Add role-based visibility and management features for products

- Introduced a role-based visibility system for products, ensuring that only users with approved roles can view specific products.
- Added new database tables for roles, user roles, and product role visibility to manage access control.
- Implemented utility functions for role management, including fetching approved roles, checking product visibility, and assigning roles to users and products.
- Updated API endpoints to filter products based on user roles, enhancing security and user experience.
- Prepared the database schema for future role request and approval workflows in upcoming phases.

docs/ARCHITECTURE.md

@@ -1505,8 +1505,49 @@ try {
 
 
 ┌─────────────────────┐
+│       Role          │
+├─────────────────────┤
+│ id (PK)             │
+│ code (UQ)           │  ('private', 'educator', 'company')
+│ display_name        │
+│ description         │
+│ requires_approval   │
+│ sort_order          │
+│ active              │
+│ created_at          │
+│ updated_at          │
+└──────────┬──────────┘
+           │
+           │ M:N
+           │
+┌──────────▼──────────┐         ┌─────────────────────┐
+│     UserRole        │         │ ProductRoleVis...   │
+├─────────────────────┤         ├─────────────────────┤
+│ id (PK)             │         │ id (PK)             │
+│ user_id (FK) ───────┼────>    │ product_id (FK) ────┼────> Product
+│ role_id (FK) ───────┼────>    │ role_id (FK) ───────┼────> Role
+│ status              │         │ created_at          │
+│ organization_name   │         └─────────────────────┘
+│ admin_notes         │
+│ status_history      │  (JSONB)
+│ created_at          │
+│ updated_at          │
+└─────────────────────┘
+```
+
+**Rollen-System (MVP - Datenbankstruktur):**
 
 - **roles**: Rollen-Definitionen (private, educator, company)
+- **user_roles**: Many-to-Many User ↔ Rollen mit Antrags-Workflow (vorbereitet für Phase 2/3)
+- **product_role_visibility**: Many-to-Many Produkt ↔ Rollen (Sichtbarkeitssteuerung)
+
+**Opt-in Sichtbarkeit:**
+- Produkte OHNE `product_role_visibility` Einträge sind für NIEMANDEN sichtbar
+- Produkte MIT Einträgen sind nur für User mit passender `approved` Rolle sichtbar
+
+### 4.2 Drizzle Schema Definition
+
+```typescript
 // server/database/schema.ts
 import {
   pgTable,

docs/PRD.md

@@ -57,6 +57,8 @@ Eine spezialisierte E-Commerce-App, die es Besuchern des experimenta Science Cen
 **Im Scope (MVP):**
 
 - Registrierung und Login
+- Rollen-Datenstruktur (private, educator, company)
+- Rollenbasierte Produktsichtbarkeit
 - Anzeige von Makerspace-Jahreskarten
 - Warenkorb-Funktionalität
 - Checkout-Prozess
@@ -65,9 +67,10 @@ Eine spezialisierte E-Commerce-App, die es Besuchern des experimenta Science Cen
 
 **Out of Scope (MVP):**
 
-- Rollen-System (Pädagogen, Unternehmen)
+- Rollen-Antrags-UI (Pädagogen, Unternehmen beantragen Rolle)
+- Admin-Panel für Rollen-Genehmigung
 - Pädagogische Jahreskarten
-- Genehmigungsworkflows
+- Genehmigungsworkflows (UI)
 - Platzreservierung
 - Multi-Payment-Provider
 - Laborkurse
@@ -100,6 +103,84 @@ Eine spezialisierte E-Commerce-App, die es Besuchern des experimenta Science Cen
 - Corporate Events
 - Teambuilding-Maßnahmen
 
+### 3.3 Rollen & Berechtigungen
+
+Das System nutzt ein rollenbasiertes Modell zur Steuerung der Produktsichtbarkeit.
+
+#### 3.3.1 Verfügbare Rollen
+
+**Private (Privatperson):**
+- Code: `private`
+- Beschreibung: Für private Besucher und Einzelpersonen
+- Genehmigung: Keine Genehmigung erforderlich (auto-approved)
+- Produkte: Makerspace-Jahreskarten, allgemeine Jahreskarten
+
+**Educator (Pädagoge):**
+- Code: `educator`
+- Beschreibung: Für Lehrer, Erzieher und pädagogische Fachkräfte
+- Genehmigung: Erforderlich (Phase 2/3)
+- Produkte: Pädagogen-Jahreskarten, Makerspace-Jahreskarten
+
+**Company (Unternehmen):**
+- Code: `company`
+- Beschreibung: Für Firmenkunden und B2B-Partner
+- Genehmigung: Erforderlich (Phase 2/3)
+- Produkte: Firmen-Jahreskarten (zukünftig)
+
+#### 3.3.2 Produktsichtbarkeit (MVP)
+
+**Grundprinzip:** Opt-in Sichtbarkeit
+
+- Produkte sind NUR sichtbar, wenn explizit Rollen zugewiesen sind
+- Produkte OHNE Rollenzuweisung sind für NIEMANDEN sichtbar
+- User OHNE genehmigte Rolle sehen KEINE Produkte
+- Unauthentifizierte User sehen KEINE Produkte
+
+**Beispiele:**
+- Makerspace-Jahreskarte → zugewiesen zu `private` + `educator` → sichtbar für beide Rollen
+- Pädagogen-Jahreskarte → zugewiesen zu `educator` → nur für Pädagogen sichtbar
+- Unzugewiesenes Produkt → für niemanden sichtbar
+
+#### 3.3.3 Rollenzuweisung (MVP)
+
+**Manuelle Zuweisung via Datenbank:**
+- Rollen werden manuell via Drizzle Studio zugewiesen
+- Status immer `approved` (keine Anträge im MVP)
+- Standard: Neue User erhalten automatisch Rolle `private`
+
+**Automatische Produkt-Rollen-Zuweisung (ERP-Import):**
+
+Beim Import von Produkten aus dem NAV ERP werden Rollen basierend auf der Kategorie automatisch zugewiesen:
+
+| Kategorie | Zugewiesene Rollen |
+|-----------|-------------------|
+| `makerspace-annual-pass` | `private`, `educator` |
+| `annual-pass` | `private` |
+| `educator-annual-pass` | `educator` |
+| `company-annual-pass` | `company` |
+
+#### 3.3.4 Antrags-Workflow (Phase 2/3)
+
+**Future Feature:** Benutzer können zusätzliche Rollen beantragen.
+
+**Prozess (geplant):**
+1. User navigiert zu "Profil" → "Rollen verwalten"
+2. User wählt Rolle (z.B. "Pädagoge")
+3. User gibt Schule/Organisation an (Freitext oder Dropdown)
+4. System erstellt Antrag mit Status `pending`
+5. Admin prüft Antrag im Admin-Panel
+6. Admin genehmigt (`approved`) oder lehnt ab (`rejected`)
+7. Bei Genehmigung: User sieht nun Produkte für diese Rolle
+8. Bei Ablehnung: User kann mit korrigierten Daten erneut beantragen
+
+**Datenbank-Vorbereitung (MVP):**
+- Tabelle `user_roles` enthält bereits Felder für Antrags-Workflow:
+  - `status`: `pending` | `approved` | `rejected`
+  - `organizationName`: Name der Schule/Firma (Freitext)
+  - `adminNotes`: Admin-Kommentare zur Genehmigung/Ablehnung
+  - `statusHistory`: JSONB-Array mit Änderungshistorie
+- Diese Felder sind vorbereitet, aber im MVP ungenutzt
+
 ---
 
 ## 4. User Stories & Use Cases