Jira-Cloud-Integration

Leiten Sie AllyProof-Verstöße nach Jira Cloud weiter – eine Website pro Jira-Projekt, konfigurierbare Schweregradschwelle pro Website, optionales Auto-Push bei Scan-Abschluss. Schließt sich das Jira-Ticket, wechselt der entsprechende Verstoß in AllyProof zu behoben. Die Integration ist für Agenturen gebaut, die mehrere Kunden-Websites auf mehreren Jira-Boards aus einer einzigen Verbindung betreiben.

Was die Integration tut

  • Pro-Website-Routing. Eine AllyProof-Organisation verbindet sich mit einer Jira-Cloud-Website, aber jede gescannte Website routet zu ihrem eigenen Jira-Projekt. ACMEs Verstöße landen auf dem ACME-Board, BetaCorps auf BETA – kein gemeinsamer Sammeltopf.
  • Schweregradschwelle pro Website. Entscheiden Sie website-weise, welche Schweregrade nach Jira fließen. Produktion kann alles pushen; Staging nur Kritisch.
  • Drei Wege zum Pushen. Eine Einzelverstoß-Schaltfläche Nach Jira pushen auf Problem-Detailseiten; eine Sammel-Schaltfläche N nach PROJECT pushen auf jeder Website-Seite; eine ausklappbare Auswahl, um genau festzulegen, welche Verstöße aus einem Scan gepusht werden.
  • Optionales Auto-Push. Pro Website aktivierbar, dann synchronisieren sich neue Verstöße automatisch nach Jira, sobald Scans abgeschlossen sind. Standardmäßig nur vorwärtsgerichtet – das Aktivieren von Auto-Push kippt niemals den historischen Rückstand hinein.
  • Status-Rücksync. Wechselt ein Jira-Ticket in einen Status der Kategorie Erledigt in Jira, markiert AllyProof den verknüpften Verstoß als behoben. Andere Übergänge überlässt die Integration Ihrem Team.
  • Idempotent und schleifensicher. Erneutes Pushen eines Verstoßes liefert den bestehenden Jira-Schlüssel zurück – nie ein Duplikat. Änderungen, die wir über die API vornehmen, sind markiert, damit ein eingehender Webhook auf unsere eigene Bearbeitung den Sync nicht erneut auslöst.

Voraussetzungen

  • Sie sind Owner oder Admin in AllyProof. Members können die Push-Schaltfläche nutzen, sobald die Verbindung besteht, aber nur ein Admin kann verbinden, Sync-Regeln konfigurieren oder trennen.
  • Sie haben eine Jira-Cloud-Website (ihre-org.atlassian.net) und die Berechtigung, Tickets in jedem Projekt zu erstellen, zu dem Sie routen möchten. Jira Server und Data Center werden derzeit nicht unterstützt.
  • Das Atlassian-Konto, mit dem Sie sich verbinden, kann die Scopes gewähren: read:jira-work, write:jira-work, read:jira-user und manage:jira-webhook.

Jira verbinden

  1. Gehen Sie zu Einstellungen → Integrationen.
  2. Klicken Sie auf Jira verbinden. Sie werden zum Zustimmungsbildschirm von Atlassian weitergeleitet.
  3. Gewähren Sie die angeforderten Scopes. Sie landen zurück auf der Integrationen-Seite mit einem "Verbunden"-Badge.
  4. Neue Verbindungen starten mit jeder Website deaktiviert. Das ist bewusst so – es verhindert, dass die Integration in dem Moment, in dem OAuth abgeschlossen ist, automatisch jede Website in ein einziges Projekt routet. Fahren Sie unten mit Sync-Regeln konfigurieren fort, um die gewünschten Websites zu aktivieren.

Sync-Regeln konfigurieren

Auf der Integrationen-Seite listet der Abschnitt Sync-Regeln jede aktive Website Ihrer Organisation als Zeile mit vier Steuerelementen auf:

  • Website-Kontrollkästchen. Aus bedeutet, diese Website ist vollständig vom Jira-Sync ausgeschlossen – weder manueller noch Auto-Push tut etwas, bis Sie es aktivieren.
  • Jira-Projekt. Der Projektschlüssel (z. B. ACME, WEB, SCRUM), in dem die Verstöße dieser Website landen sollen. Finden Sie ihn in Jira unter Projekteinstellungen → Details. Eine Website kann ohne diesen nicht pushen – die Zeile zeigt eine gelbe Warnung, wenn er leer ist.
  • Schweregrade. Pro-Website-Auswahl für Kritisch, Schwerwiegend, Moderat, Gering. Nur Verstöße, deren Auswirkung einer der angekreuzten Stufen entspricht, können für diese Website nach Jira fließen. Die meisten Teams beschränken sich auf Kritisch + Schwerwiegend, um Jira auf wichtige Behebungsarbeit fokussiert zu halten.
  • Auto-Push. Aus (Standard) bedeutet, neue Verstöße bleiben in AllyProof, bis jemand auf Push klickt. An bedeutet, neue Verstöße werden automatisch gepusht, sobald jeder Scan abgeschlossen ist – siehe Auto-Push unten für die Vorwärtsgerichtet-Absicherung.

Klicken Sie nach Änderungen auf Sync-Regeln speichern. Die Schaltfläche aktiviert sich nur, wenn sich etwas geändert hat und jede aktive Website einen Projektschlüssel hat.

Verstöße pushen

Schaltfläche pro Verstoß

Klicken Sie auf jeder Problem-Detailseite auf Nach Jira pushen. Die Schaltfläche wird durch einen direkten Link zum erstellten Ticket ersetzt, sobald der Aufruf abgeschlossen ist (meist unter zwei Sekunden). Nachfolgende Aufrufe dieses Verstoßes zeigen den Jira-Schlüssel statt der Push-Schaltfläche. Die Schaltfläche ist automatisch mit einem Tooltip deaktiviert, wenn:

  • Die Website vom Sync ausgeschlossen ist
  • Für die Website kein Jira-Projektschlüssel konfiguriert ist
  • Der Schweregrad des Verstoßes unter der Schwelle dieser Website liegt

Sammel-Push von einer Website

Auf jeder Website-Seite (nach Abschluss eines Scans) fasst ein Jira-Sync-Block die Beziehung dieser Website zu Jira zusammen:

  • N Verstöße bereit zum Pushen nach PROJECT. Klicken Sie auf N nach PROJECT pushen, um alle passenden ungepushten Verstöße auf einmal zu versenden. Pushes sind getaktet (~150 ms Abstand), um unter Jiras Ratenlimits zu bleiben.
  • M bereits verknüpft. Verstöße, die bereits ein Jira-Ticket aus früheren Scans haben, werden zur Transparenz angezeigt, aber nicht erneut gepusht.
  • Alle passenden Verstöße sind in PROJECT. Stille Bestätigung, wenn nichts aussteht.

Auswahl pro Verstoß

Klicken Sie im Sammel-Push-Block auf Verstöße auswählen, um eine Checkliste aufzuklappen. Jeder pushbare Verstoß wird mit seinem Schweregrad-Badge, seiner Beschreibung, Seitenzahl und WCAG-Tags aufgelistet; alle Zeilen sind vorausgewählt, sodass das Standardverhalten der eingeklappten Schaltfläche entspricht. Deaktivieren Sie Zeilen, die Sie überspringen möchten – die primäre Aktion wird zu N ausgewählte pushen. Der Server validiert jede ID erneut gegen Ihre Sync-Regeln, damit ein veralteter Tab sie nicht umgehen kann.

Auto-Push

Steht Auto-Push für eine Website auf An, wird jeder neue Verstoß, der in einem Scan erkannt wird und den Regeln der Website entspricht, automatisch nach Jira gepusht, sobald der Scan abgeschlossen ist. Drei Garantien:

  • Nur vorwärtsgerichtet. Das Aktivieren von Auto-Push setzt einen Seit-Zeitstempel; nur Verstöße, die zu diesem Zeitpunkt oder danach erstmals erkannt wurden, sind berechtigt. Der historische Rückstand bleibt manuellem/Sammel-Push überlassen, sodass das Umlegen des Schalters nie 200 Tickets auf einmal in Jira ablädt.
  • Gleiche Regeln gelten. Auto-Push durchläuft dieselben Pro-Website-Projekt-, Schweregrad- und Ausschlussschranken wie der manuelle Ablauf. Verschärfen Sie Regeln, gilt die Änderung sofort für den nächsten Auto-Push.
  • Idempotent. Derselbe Dedup-Schlüssel wird wie bei manuellen Pushes verwendet; ein erneuter Scan, der denselben Verstoß wieder erkennt, erstellt nie ein doppeltes Ticket.

Das Ausschalten von Auto-Push stoppt die Automatisierung sofort. Späteres erneutes Aktivieren setzt einen neuen Seit-Stichtag – die Zeit zwischen Aus und An wird als Rückstand behandelt, nicht rückwirkend automatisch gepusht.

Status-Rücksync zu AllyProof

Wechselt die Statuskategorie des Jira-Tickets zu Erledigt, wechselt AllyProof den verknüpften Verstoß zu resolved. Nichts anderes in Jira wird interpretiert – wir spiegeln bewusst nicht Jiras In Bearbeitung in unseren Workflow zurück, da Ihr AllyProof-Team das Problem möglicherweise bereits über das Dashboard dorthin verschoben hat, und zweiseitiges Live-Spiegeln in diesem Zwischenzustand ist die klassische Quelle für Abweichungen.

Authentifizierung, Tokens und Sicherheit

  • Wir nutzen Atlassians OAuth-2.0-(3LO)-Flow – keine API-Tokens, keine geteilten Passwörter.
  • Zugriffs- und Refresh-Tokens werden ruhend verschlüsselt (AES-256-GCM) mit einem serverseitig verwalteten Schlüssel, bevor sie die Datenbank erreichen.
  • Atlassians Refresh-Tokens rotieren bei jeder Nutzung; wir speichern das neue Paar atomar erneut, sodass ein wiederholter alter Refresh abgelehnt wird.
  • Eingehende Webhooks von Atlassian tragen ein mit dem Client-Secret unserer App HS256-signiertes JWT – wir verifizieren es, bevor wir den Anfrage-Body anfassen, und deduplizieren nach (Ereignis + Ticket + Zeitstempel), damit eine Wiederholung keine Statusänderung erneut anwendet.

Trennen

Klicken Sie unter Einstellungen → Integrationen auf Jira trennen. Die Verbindung wird weich gelöscht (wir behalten die Zeile für Audit-Zwecke), Tokens werden auf unserer Seite widerrufen, der eingehende Webhook wird bei Atlassian deregistriert, und alle Push-Wege stoppen sofort. Bestehende Verstoß-zu-Ticket-Verknüpfungen bleiben in AllyProof als historische Datensätze erhalten, synchronisieren sich aber nicht mehr.

Grenzen und Vorbehalte

  • Eine Jira-Cloud-Website pro AllyProof-Organisation. Mehrere Projekte innerhalb dieser Website werden über Pro-Website-Routing vollständig unterstützt.
  • Atlassians dynamische Webhooks laufen nach 30 Tagen ab. Wir erneuern sie automatisch nach Zeitplan; keine manuelle Aktion nötig.
  • Sammel-Push ist mit ~150 ms zwischen Aufrufen getaktet und respektiert Atlassians Retry-After-Header bei 429 mit exponentiellem Backoff. Bei sehr großen Rückständen (Hunderte Verstöße beim ersten Push) rechnen Sie damit, dass der Batch ein bis zwei Minuten dauert – er streamt im Hintergrund nach Jira, und die Seite aktualisiert sich, wenn er fertig ist.
  • Schweregradregel-Änderungen greifen beim nächsten Push (manuell oder automatisch). Bereits gepushte Tickets werden nicht rückwirkend zurückgerufen, wenn Sie den Filter verschärfen – die Idempotenzgarantie gewinnt bewusst gegenüber nachträglichen Regeländerungen.
  • Brauchen Sie Hilfe bei einem bestimmten Routing-Setup oder stoßen auf eine Sperre / 403 von Jira? Eröffnen Sie eine Support-Anfrage, und wir schauen uns die Logs gemeinsam an.