# Redmine Ticket-Portal (Prototyp)

Vorgeschaltete Webseite fuer die Ticket-Anlage mit verpflichtendem Kundenbezug
(Loesungsvariante 1 aus dem Ticket). Die Kundenauswahl laeuft ueber ein
Autocomplete gegen die eigenen Stammdaten - die 1500 Kunden muessen also
nicht als Auswahlliste in Redmine gepflegt werden. Die Kundennummer wird in
ein Text-Custom-Field des Tickets geschrieben.

## Ablauf

1. Techniker sucht den Kunden per Nummer oder Firmenname (Autocomplete)
2. Betreff und Beschreibung erfassen
3. Der Server validiert die Kundennummer gegen die Stammdaten und legt das
   Ticket per POST /issues.json in Redmine an (API-Key nur serverseitig)

## Setup

    npm install
    cp .env.example .env    # Werte anpassen (API-Key, Projekt, Feld-ID)
    npm start

Ohne gesetzten REDMINE_API_KEY laeuft der Server im Trockenlauf: die
Oberflaeche funktioniert komplett, Tickets werden aber nur simuliert.
Zum schnellen Ausprobieren reicht daher:

    npm install && npm run start:dry

Danach http://localhost:3000 oeffnen.

## Konfiguration (.env)

| Variable            | Bedeutung                                          |
|---------------------|----------------------------------------------------|
| REDMINE_URL         | Basis-URL der Redmine-Installation                 |
| REDMINE_API_KEY     | API-Key eines technischen Users (Recht: Tickets anlegen) |
| REDMINE_PROJECT_ID  | Ziel-Projekt fuer neue Tickets                     |
| REDMINE_TRACKER_ID  | Tracker (z. B. Support)                            |
| CUSTOMER_FIELD_ID   | ID des Custom Fields fuer die Kundennummer         |
| CUSTOMERS_FILE      | CSV mit den Kundenstammdaten (Nummer;Name)         |

Die Feld-ID laesst sich per GET /custom_fields.json ermitteln.

## Naechste Schritte Richtung Produktion

- Kundenliste direkt aus CRM/ERP ziehen (DB-View oder Export per Cron)
- Authentifizierung fuer die Techniker (z. B. LDAP/SSO im Reverse Proxy)
- WS-Nummer als zweites Custom Field automatisch mitschreiben
- HTTPS und Betrieb hinter dem vorhandenen Reverse Proxy