# Trustee Feature - RBAC Architektur & Gateway-Readiness

## Übersicht

Dieses Dokument beschreibt die **vereinfachte RBAC-Architektur** für das Trustee Feature.

**Erstellungsdatum**: 2026-01-23  
**Letzte Änderung**: 2026-01-24  
**Status**: Aktuell

---

## WICHTIG: Architektur-Änderung (2026-01-24)

### Feature-Instanz = Organisation

Die ursprüngliche Architektur sah vor, dass innerhalb einer Feature-Instanz mehrere "Organisationen" (Kunden) verwaltet werden. **Dies wurde geändert:**

- **Neu**: Eine Feature-Instanz repräsentiert **eine** Organisation (z.B. "SOHA Treuhand")
- **Entfernt**: `TrusteeOrganisation`, `TrusteeContract`, `TrusteeRole`, `TrusteeAccess`
- **Beibehalten**: `TrusteePosition`, `TrusteeDocument`, `TrusteePositionDocument`

### Vereinfachtes Datenmodell

```
Feature-Instanz (= Organisation, z.B. "SOHA Treuhand")
  └── TrusteePosition (Buchungspositionen, Konten)
  └── TrusteeDocument (Belege, Berichte)
  └── TrusteePositionDocument (Zuordnung Position ↔ Dokument)
```

---

## 1. Gateway-Status

### 1.1 Ist das Gateway bereit für UI-Arbeit?

**Ja, das Gateway ist vollständig bereit.**

| Komponente | Datei | Status |
|------------|-------|--------|
| **Routes** | `routeFeatureTrustee.py` | ✅ Komplett |
| **Interface** | `interfaceFeatureTrustee.py` | ✅ Komplett |
| **Datamodel** | `datamodelFeatureTrustee.py` | ✅ Komplett |
| **RBAC** | Via System-Level AccessRules | ✅ Implementiert |

### 1.2 Verfügbare API-Endpoints

Alle Endpoints verwenden das URL-Pattern: `/api/trustee/{instanceId}/...`

| Endpoint-Gruppe | Basis-Route | CRUD | Options |
|-----------------|-------------|------|---------|
| Documents | `/api/trustee/{instanceId}/documents` | ✅ | ✅ |
| Positions | `/api/trustee/{instanceId}/positions` | ✅ | ✅ |
| Position-Documents | `/api/trustee/{instanceId}/position-documents` | ✅ | - |
| **Instance-Roles** | `/api/trustee/{instanceId}/instance-roles` | ✅ | - |
| **User Options** | `/api/users/options` | - | ✅ |

### 1.3 Frontend Views

| View | Pfad | Beschreibung |
|------|------|--------------|
| Dashboard | `/dashboard` | Übersicht |
| Positionen | `/positions` | Buchungspositionen verwalten |
| Dokumente | `/documents` | Belege/Berichte verwalten |
| Zuordnungen | `/position-documents` | Position ↔ Dokument Zuordnungen |
| Rollen & Rechte | `/instance-roles` | Instanz-Rollen verwalten (nur Admin) |

---

## 2. RBAC-Architektur (Vereinfacht)

### 2.1 Nur System-Level RBAC

Da die Feature-Instanz selbst die Organisation repräsentiert, ist **kein Feature-internes RBAC** mehr nötig.

```
┌─────────────────────────────────────────────────────────────────────────┐
│                         SYSTEM-RBAC (Basis-Level)                       │
│                   (Mandate + Feature Instance Zugang)                    │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  User ──► UserMandate ──► Mandate                                        │
│    │                                                                     │
│    └──► FeatureAccess ──► FeatureInstance (= Organisation)              │
│              │                                                           │
│              └── Role (trustee-admin, trustee-accountant, trustee-client)│
│                    │                                                     │
│                    └── AccessRules (UI, DATA, RESOURCE)                 │
│                                                                          │
│  Frage: Hat der User überhaupt Zugang zu diesem Feature?                │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     STUFE 2: FEATURE-SPEZIFISCHES RBAC                  │
│                      (Isolation innerhalb des Features)                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  TrusteeAccess                                                           │
│  ├── userId          → Welcher User                                      │
│  ├── organisationId  → Welcher Kunde (Isolationsobjekt)                 │
│  ├── roleId          → Welche Feature-Rolle (admin, operate, userreport)│
│  └── contractId      → Optional: Einschränkung auf bestimmten Vertrag   │
│                                                                          │
│  Frage: Welche Kunden darf der User sehen? Mit welchen Rechten?         │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘
```

### 2.3 Vergleich: System-RBAC vs. Feature-RBAC

| Aspekt | System-RBAC | Feature-RBAC (Trustee) |
|--------|-------------|------------------------|
| **Tabelle** | `AccessRule` | `TrusteeAccess` |
| **Scope** | Global / Mandate | Feature-Instanz |
| **Objekte** | Tables, UI-Items, API-Resources | Organisationen, Contracts |
| **Verwaltung** | SysAdmin | Feature-Admin |
| **Zweck** | "Was darf der User technisch?" | "Welche Daten darf der User sehen?" |

### 2.4 Feature-spezifische Rollen

Das Trustee-Feature definiert drei Rollen:

| Rolle | Beschreibung | Berechtigungen |
|-------|--------------|----------------|
| **admin** | Feature-Administrator | Voller CRUD auf Organisation + alle Contracts |
| **operate** | Sachbearbeiter | CRUD für Contracts, Documents, Positions |
| **userreport** | Endbenutzer | Nur eigene erstellte Records (Documents, Positions) |

### 2.5 Contract-Level Isolation (optional)

`TrusteeAccess.contractId` ermöglicht feinere Isolation:

- **Leer/NULL**: Zugriff auf alle Contracts der Organisation
- **Gesetzt**: Zugriff nur auf diesen spezifischen Contract

```
Beispiel:
- User A hat Zugriff auf Organisation "Kunde-X" mit contractId=NULL
  → Sieht alle Contracts von Kunde-X

- User B hat Zugriff auf Organisation "Kunde-X" mit contractId="contract-123"
  → Sieht nur Contract "contract-123" von Kunde-X
```

---

## 3. Implementierung im Gateway

### 3.1 Datenmodell: TrusteeAccess

```python
class TrusteeAccess(BaseModel):
    id: str                    # UUID
    organisationId: str        # FK zu TrusteeOrganisation
    roleId: str                # FK zu TrusteeRole (admin, operate, userreport)
    userId: str                # FK zu User
    contractId: Optional[str]  # Optional: FK zu TrusteeContract
    mandateId: Optional[str]   # System-Kontext
    featureInstanceId: Optional[str]  # Feature-Instanz
```

### 3.2 Kombinierte Berechtigungsprüfung

Die Methode `checkCombinedPermission()` in `interfaceFeatureTrustee.py` kombiniert beide Stufen:

```python
def checkCombinedPermission(self, modelClass, operation, organisationId, contractId, recordCreatedBy):
    """
    Kombiniert System-RBAC + Feature-Level RBAC.
    
    1. Prüft System-RBAC (AccessLevel: ALL, GROUP, MY, NONE)
    2. Bei ALL: Bypass Feature-Level (SysAdmin)
    3. Sonst: Prüft TrusteeAccess für User + Organisation + Contract
    """
    
    # Stufe 1: System-RBAC
    accessLevel = self.getRbacAccessLevel(modelClass, operation)
    if accessLevel == AccessLevel.NONE:
        return False
    if accessLevel == AccessLevel.ALL:
        return True  # SysAdmin bypass
    
    # Stufe 2: Feature-RBAC via TrusteeAccess
    roles = self.getUserTrusteeRoles(self.userId, organisationId, contractId)
    
    if "admin" in roles:
        return True
    if "operate" in roles and modelClass in (TrusteeContract, TrusteeDocument, ...):
        return True
    if "userreport" in roles and recordCreatedBy == self.userId:
        return True
    
    return False
```

### 3.3 Automatische Filterung

Die Methode `filterRecordsByTrusteeAccess()` filtert Ergebnisse basierend auf User-Zugriff:

```python
def filterRecordsByTrusteeAccess(self, records, modelClass):
    """
    Filtert Records basierend auf TrusteeAccess des Users.
    
    - admin: Sieht alle Records der Organisation
    - operate: Sieht alle Records der Organisation
    - userreport: Sieht nur eigene Records (_createdBy = userId)
    """
```

---

## 4. Generisches Muster für andere Features

### 4.1 Feature-Isolation-Pattern

Jedes Feature kann sein eigenes Isolationsmodell definieren:

```
{Feature}Access: User → {Isolationsobjekt} → Role [→ Unter-Objekt]
```

### 4.2 Beispiele für andere Features

| Feature | Access-Tabelle | Isolationsobjekt | Unter-Objekt |
|---------|----------------|------------------|--------------|
| **Trustee** | `TrusteeAccess` | Organisation (Kunde) | Contract |
| **RealEstate** | `RealEstateAccess` | Property (Liegenschaft) | Unit (Wohnung) |
| **ProjectMgmt** | `ProjectAccess` | Project | - |
| **Accounting** | `AccountingAccess` | Company | FiscalYear |

### 4.3 Implementierungsvorlage

Für ein neues Feature mit Isolation:

1. **Datamodel**: `{Feature}Access` mit `userId`, `{isolationObject}Id`, `roleId`
2. **Interface**: `checkCombinedPermission()` und `filterRecordsByAccess()`
3. **Routes**: CRUD für `{Feature}Access`
4. **Roles**: Feature-spezifische Rollen definieren

---

## 5. API-Referenz für UI-Entwicklung

### 5.1 Access-Verwaltung (User-Zuweisung zu Kunden)

```
# Alle Access-Records abrufen
GET /api/trustee/{instanceId}/access

# Access für bestimmte Organisation
GET /api/trustee/{instanceId}/access/organisation/{orgId}

# Access für bestimmten User
GET /api/trustee/{instanceId}/access/user/{userId}

# Neuen Access erstellen (User zu Kunde zuweisen)
POST /api/trustee/{instanceId}/access
Body: {
  "userId": "user-uuid",
  "organisationId": "kunde-id",
  "roleId": "operate",
  "contractId": null  // Optional
}

# Access aktualisieren
PUT /api/trustee/{instanceId}/access/{accessId}

# Access löschen
DELETE /api/trustee/{instanceId}/access/{accessId}
```

### 5.2 Options-Endpoints für Dropdowns

```
# Organisationen für Dropdown
GET /api/trustee/{instanceId}/organisations/options
→ [{ "value": "org-id", "label": "Kunde AG" }, ...]

# Rollen für Dropdown
GET /api/trustee/{instanceId}/roles/options
→ [{ "value": "admin", "label": "Administrator" }, ...]

# Contracts für Dropdown (dynamisch nach Organisation)
GET /api/trustee/{instanceId}/contracts/options
→ [{ "value": "contract-uuid", "label": "Vertrag 2026" }, ...]

# Users für Dropdown (aus aktuellem Mandate)
GET /api/users/options
→ [{ "value": "user-uuid", "label": "Max Muster" }, ...]
```

---

## 6. UI-Anforderungen

### 6.1 Access-View (User-Verwaltung)

Eine View zur Verwaltung der User-Zuweisungen:

| Spalte | Typ | Quelle |
|--------|-----|--------|
| User | Select | `/api/users/options` |
| Organisation | Select | `/api/trustee/{instanceId}/organisations/options` |
| Rolle | Select | `/api/trustee/{instanceId}/roles/options` |
| Contract | Select (optional) | `/api/trustee/{instanceId}/contracts/options` |

**Hinweis**: Das `contractId` Dropdown sollte dynamisch nach Auswahl der Organisation gefiltert werden.

### 6.2 Berechtigungen für Access-View

- **Sichtbar für**: Feature-Admins (`admin` Rolle in mindestens einer Organisation)
- **Create/Update/Delete**: Nur für Organisationen, in denen User Admin ist

---

## 7. Offene Punkte / Entscheidungen

### 7.1 Geklärt

- [x] Ist das Gateway bereit? → **Ja**
- [x] Sind Feature-spezifische Rollen gleich wie System-Rollen? → **Nein, bewusst getrennt**
- [x] Ist zweistufiges RBAC nötig? → **Ja, bereits implementiert**
- [x] Existiert der Users-Options-Endpoint? → **Ja, `/api/users/options`**

### 7.2 Offen für UI-Review

- [ ] Soll die Access-View eine eigene Seite sein oder Tab in Organisation?
- [ ] Wie wird Contract-Dropdown bei organisationId-Änderung aktualisiert?
- [ ] Braucht es eine "Bulk-Zuweisung" (User zu mehreren Orgs gleichzeitig)?

---

## 8. Zusammenfassung

### Das Gateway bietet:

1. **Vollständige CRUD-Routes** für alle Trustee-Entities
2. **Zwei-Stufen-RBAC** (System + Feature-Level)
3. **Automatische Filterung** basierend auf User-Access
4. **Options-Endpoints** für alle Dropdowns

### Das UI muss implementieren:

1. **Access-View** zur Verwaltung von User-Zuweisungen
2. **Dynamische Dropdowns** mit Abhängigkeiten (Contract nach Organisation)
3. **instanceId** in allen API-Calls verwenden

### Architektur-Prinzip:

```
System-RBAC → Zugang zum Feature
Feature-RBAC → Isolation innerhalb des Features
```

---

## 9. Implementierungsplan: Fehlende Elemente

### 9.1 Aktueller Stand (Analyse)

| Komponente | Status | Details |
|------------|--------|---------|
| **Gateway (Backend)** | ✅ Komplett | Routes, Interface, Datamodel, RBAC |
| **API Hooks** (`useTrustee.ts`) | ✅ Komplett | CRUD-Hooks für alle Entities |
| **API Client** (`trusteeApi.ts`) | ✅ Komplett | Alle Endpoints implementiert |
| **Views (Grundgerüst)** | ⚠️ Teilweise | Tabellen existieren, aber ohne Forms |
| **Create/Edit Formulare** | ❌ Fehlt | Buttons vorhanden, aber ohne Funktion |
| **Label-Auflösung** | ❌ Fehlt | Zeigt IDs statt Labels (userId, orgId) |
| **Dynamische Dropdowns** | ❌ Fehlt | Contract abhängig von Organisation |

### 9.2 Fehlende Implementierungen

#### P1: Create/Edit Formulare für alle Views

**Problem:** Die "Neu erstellen" und "Bearbeiten" Buttons existieren, aber öffnen kein Formular.

**Betroffene Views:**
- `TrusteeOrganisationsView.tsx`
- `TrusteeRolesView.tsx`
- `TrusteeAccessView.tsx`
- `TrusteeContractsView.tsx`
- `TrusteeDocumentsView.tsx`
- `TrusteePositionsView.tsx`

**Lösung:** Pro View ein Modal mit EditForm implementieren, das die automatisch generierten Felder aus `generateEditFieldsFromAttributes()` verwendet.

**Beispiel-Pattern:**

```tsx
// In TrusteeOrganisationsView.tsx
const [isModalOpen, setIsModalOpen] = useState(false);
const [editingItem, setEditingItem] = useState<TrusteeOrganisation | null>(null);
const { generateCreateFieldsFromAttributes, generateEditFieldsFromAttributes } = useTrusteeOrganisations();
const { handleCreate, handleUpdate } = useTrusteeOrganisationOperations();

// Create-Button
<button onClick={() => { setEditingItem(null); setIsModalOpen(true); }}>
  + Neue Organisation
</button>

// Edit-Button
<button onClick={() => { setEditingItem(org); setIsModalOpen(true); }}>
  ✏️
</button>

// Modal mit EditForm
<Modal isOpen={isModalOpen} onClose={() => setIsModalOpen(false)}>
  <EditForm
    fields={editingItem ? generateEditFieldsFromAttributes() : generateCreateFieldsFromAttributes()}
    initialData={editingItem || {}}
    onSave={async (data) => {
      if (editingItem) {
        await handleUpdate(editingItem.id, data);
      } else {
        await handleCreate(data);
      }
      setIsModalOpen(false);
      refetch();
    }}
  />
</Modal>
```

---

#### P2: Label-Auflösung für Foreign Keys

**Problem:** `TrusteeAccessView` zeigt:
- `userId: "uuid-123"` statt `"Max Muster"`
- `organisationId: "org-1"` statt `"Kunde AG"`
- `roleId: "admin"` statt `"Administrator"`

**Lösung:** Options aus den entsprechenden Endpoints laden und als Lookup-Map verwenden.

**Implementierung:**

```tsx
// In TrusteeAccessView.tsx
const [userOptions, setUserOptions] = useState<{value: string, label: string}[]>([]);
const [orgOptions, setOrgOptions] = useState<{value: string, label: string}[]>([]);
const [roleOptions, setRoleOptions] = useState<{value: string, label: string}[]>([]);

useEffect(() => {
  const loadOptions = async () => {
    const [users, orgs, roles] = await Promise.all([
      api.get('/api/users/options'),
      api.get(`/api/trustee/${instanceId}/organisations/options`),
      api.get(`/api/trustee/${instanceId}/roles/options`)
    ]);
    setUserOptions(users.data);
    setOrgOptions(orgs.data);
    setRoleOptions(roles.data);
  };
  loadOptions();
}, [instanceId]);

// Lookup-Funktion
const getLabel = (options: {value: string, label: string}[], value: string) => 
  options.find(o => o.value === value)?.label || value;

// In der Tabelle
<td>{getLabel(userOptions, access.userId)}</td>
<td>{getLabel(orgOptions, access.organisationId)}</td>
<td>{getLabel(roleOptions, access.roleId)}</td>
```

---

#### P3: Dynamische Dropdown-Filterung

**Problem:** Im AccessView/ContractView soll das Contract-Dropdown nur Contracts der ausgewählten Organisation zeigen.

**Lösung:** `dependsOn`-Attribut im Datamodel nutzen + dynamisches Nachladen.

**Implementierung im EditForm:**

```tsx
// Wenn organisationId geändert wird, Contracts neu laden
const handleFieldChange = async (fieldKey: string, value: any) => {
  setFormData(prev => ({ ...prev, [fieldKey]: value }));
  
  // Dynamische Abhängigkeiten prüfen
  const dependentFields = fields.filter(f => f.dependsOn === fieldKey);
  for (const depField of dependentFields) {
    if (depField.optionsReference?.includes('contracts')) {
      // Contracts für diese Organisation laden
      const contracts = await api.get(
        `/api/trustee/${instanceId}/contracts/options?organisationId=${value}`
      );
      // Options aktualisieren...
    }
  }
};
```

**Backend-Erweiterung nötig:** Der `/contracts/options` Endpoint muss einen `organisationId` Query-Parameter unterstützen.

---

#### P4: Generischer Options-Hook

**Problem:** Options-Laden ist in jeder View dupliziert.

**Lösung:** Zentraler Hook für Trustee-Options.

```tsx
// hooks/useTrusteeOptions.ts
export function useTrusteeOptions() {
  const instanceId = useInstanceId();
  const [options, setOptions] = useState<TrusteeOptionsMap>({});
  
  const loadOptions = useCallback(async (entity: 'organisations' | 'roles' | 'contracts' | 'users') => {
    if (entity === 'users') {
      const res = await api.get('/api/users/options');
      setOptions(prev => ({ ...prev, users: res.data }));
    } else {
      const res = await api.get(`/api/trustee/${instanceId}/${entity}/options`);
      setOptions(prev => ({ ...prev, [entity]: res.data }));
    }
  }, [instanceId]);
  
  const getLabel = useCallback((entity: string, value: string) => {
    return options[entity]?.find(o => o.value === value)?.label || value;
  }, [options]);
  
  return { options, loadOptions, getLabel };
}
```

---

### 9.3 Implementierungsreihenfolge

| Phase | Aufgabe | Aufwand | Priorität |
|-------|---------|---------|-----------|
| **1** | `useTrusteeOptions` Hook erstellen | 2h | Hoch |
| **2** | Label-Auflösung in allen Views | 3h | Hoch |
| **3** | Create/Edit Modal in `TrusteeOrganisationsView` | 3h | Hoch |
| **4** | Create/Edit Modal für alle anderen Views kopieren | 4h | Mittel |
| **5** | Dynamische Contract-Filterung | 2h | Mittel |
| **6** | Backend: `/contracts/options?organisationId=` | 1h | Mittel |
| **7** | Position-Document Verknüpfungs-UI | 4h | Niedrig |
| **8** | Testing & Bugfixes | 4h | Hoch |

**Geschätzter Gesamtaufwand:** ~23h (3-4 Arbeitstage)

---

### 9.4 Detailplan Phase 1-3 (MVP)

#### Schritt 1: `useTrusteeOptions` Hook

**Datei:** `frontend_nyla/src/hooks/useTrusteeOptions.ts`

```typescript
/**
 * Hook für Trustee-Options (Dropdowns, Label-Auflösung)
 */
import { useState, useCallback, useEffect } from 'react';
import api from '../api';
import { useInstanceId } from './useCurrentInstance';

interface Option {
  value: string;
  label: string;
}

interface TrusteeOptions {
  users: Option[];
  organisations: Option[];
  roles: Option[];
  contracts: Option[];
  documents: Option[];
  positions: Option[];
}

export function useTrusteeOptions(autoLoad: (keyof TrusteeOptions)[] = []) {
  const instanceId = useInstanceId();
  const [options, setOptions] = useState<Partial<TrusteeOptions>>({});
  const [loading, setLoading] = useState(false);

  const loadOptions = useCallback(async (
    entities: (keyof TrusteeOptions)[],
    filters?: { organisationId?: string }
  ) => {
    if (!instanceId) return;
    setLoading(true);

    try {
      const promises = entities.map(async (entity) => {
        let url: string;
        if (entity === 'users') {
          url = '/api/users/options';
        } else {
          url = `/api/trustee/${instanceId}/${entity}/options`;
          if (filters?.organisationId && entity === 'contracts') {
            url += `?organisationId=${filters.organisationId}`;
          }
        }
        const res = await api.get(url);
        return { entity, data: res.data };
      });

      const results = await Promise.all(promises);
      const newOptions: Partial<TrusteeOptions> = {};
      results.forEach(({ entity, data }) => {
        newOptions[entity] = data;
      });
      setOptions(prev => ({ ...prev, ...newOptions }));
    } finally {
      setLoading(false);
    }
  }, [instanceId]);

  const getLabel = useCallback((entity: keyof TrusteeOptions, value: string): string => {
    return options[entity]?.find(o => o.value === value)?.label || value;
  }, [options]);

  // Auto-Load bei Mount
  useEffect(() => {
    if (autoLoad.length > 0 && instanceId) {
      loadOptions(autoLoad);
    }
  }, [instanceId, autoLoad.join(',')]);

  return { options, loadOptions, getLabel, loading };
}
```

#### Schritt 2: TrusteeAccessView mit Labels

**Datei:** `frontend_nyla/src/pages/views/trustee/TrusteeAccessView.tsx`

- Import `useTrusteeOptions`
- Auto-Load: `['users', 'organisations', 'roles']`
- Tabelle: `getLabel()` für userId, organisationId, roleId

#### Schritt 3: Create/Edit Modal

**Ansatz:** Bestehende `EditPopup`-Komponente aus anderen Views (z.B. Prompts) wiederverwenden.

**Dateien:**
- `TrusteeOrganisationsView.tsx` - Modal hinzufügen
- Nutzt `generateCreateFieldsFromAttributes()` für Feld-Definitionen
- `handleCreate()` / `handleUpdate()` für API-Calls

---

### 9.5 Backend-Erweiterung (optional)

Für dynamische Contract-Filterung nach Organisation:

**Datei:** `gateway/modules/features/trustee/routeFeatureTrustee.py`

```python
@router.get("/{instanceId}/contracts/options", response_model=List[Dict[str, Any]])
async def getContractOptions(
    request: Request,
    instanceId: str = Path(...),
    organisationId: Optional[str] = Query(None),  # NEU
    context: RequestContext = Depends(getRequestContext)
) -> List[Dict[str, Any]]:
    """Get contract options, optionally filtered by organisation."""
    mandateId = await _validateInstanceAccess(instanceId, context)
    interface = getInterface(context.user, mandateId=mandateId, featureInstanceId=instanceId)
    
    if organisationId:
        contracts = interface.getContractsByOrganisation(organisationId)
    else:
        result = interface.getAllContracts(None)
        contracts = result.items if hasattr(result, 'items') else result
    
    return [{"value": c.id, "label": c.label or c.name or c.id} for c in contracts]
```

---

### 9.6 Offene Entscheidungen für Review

| # | Frage | Optionen |
|---|-------|----------|
| 1 | **Modal vs. Inline-Edit** | A) Modal-Dialog / B) Inline in Tabelle / C) Separate Seite |
| 2 | **Bulk-Operationen** | A) Ja, Multi-Select + Batch-Aktionen / B) Nein, nur einzeln |
| 3 | **Position-Document UI** | A) Separate View / B) Inline in Position-View / C) Beides |
| 4 | **Validierung** | A) Client-only / B) Server-only / C) Beides |

---

**Dokumentversion**: 1.1  
**Letzte Aktualisierung**: 2026-01-23  
**Autor**: Claude (AI-Assistent)  
**Status**: Zur Überprüfung