Jira JQL: = und IN auf Textfeldern werden zur exakten Phrasensuche

Von Rustem Shiriiazdanov•6. Oktober 2026•Lesedauer: 8 Minuten

TL;DR

Atlassian hat am 6. Oktober 2026 angekündigt (CHANGE-3440), dass =, IN und NOT IN auf Textfeldern künftig eine exakte Phrasensuche ausführen statt eines Abgleichs des gesamten Feldwerts. Das Beispiel von Atlassian: textField = "urgent" findet „urgent“, „urgent issue“ und „very urgent issue“, nicht nur ein Feld, dessen gesamter Wert „urgent“ lautet.

• = und IN werden breiter: Filter, Gadgets und Automatisierungsregeln können mehr Vorgänge zurückgeben.
• NOT IN wird enger: Es schließt jeden Vorgang aus, dessen Text die Phrase enthält.
• Sie können die Ergebnisse schon heute prüfen: Atlassian beschreibt das neue = als dieselbe Suche wie ~ mit maskierten Anführungszeichen, also textField ~ "\"urgent\"".

Auf den beiden Cloud-Sites, die wir geprüft haben, noch nicht aktiv (6. Oktober 2026): Beim Feld Epic Name, das = akzeptiert, verglich der Operator weiterhin den gesamten Wert. Summary und die anderen Standard-Textfelder lehnen = weiterhin ab. Die folgenden Ergebnisse stammen aus der gleichwertigen ~-Abfrage, ausgeführt auf 12 Demo-Arbeitselementen einer Test-Site.

Was sich genau ändert

Der Operator vergleicht nicht mehr den gesamten Wert, sondern sucht die Phrase an beliebiger Stelle im Text. Die Regeln laut Atlassian:

Die linke Seite wendet die alte Regel (gesamter Wert) so an, wie Atlassian sie beschreibt; Summary selbst hat = nie akzeptiert. Die rechte Seite zeigt, was summary ~ "\"urgent issue\"" auf unserer Test-Site zurückgegeben hat.

Welche Felder sind betroffen? Die Ankündigung nennt sie nicht. Auf beiden geprüften Sites lehnt Jira =, !=, IN und NOT IN auf Summary, Description, Environment, Comment sowie auf benutzerdefinierten Feldern vom Typ Kurztext und Absatz weiterhin ab („The operator ‚=‘ is not supported by the ’summary‘ field“) und speichert keinen Filter mit solchem JQL. Einige Felder mit Zeichenkettenwerten akzeptieren = und IN bereits, zum Beispiel URL-Felder und manche Felder von Atlassian oder von Apps. Prüfen Sie beide Gruppen; das Skript weiter unten deckt sie ab.

Ist die Änderung schon aktiv? Auf unseren beiden Sites nicht, Stand 6. Oktober 2026. Das Feld Epic Name akzeptiert sowohl = als auch ~ und zeigt daher, welche Regel gerade gilt. = verglich auf beiden Sites weiterhin den gesamten Wert:

Führen Sie die dritte Abfrage mit einem Epic Name auf Ihrer eigenen Site aus. Sobald sie das Epic zurückgibt, ist die Änderung bei Ihnen angekommen.

Heute wird summary = "Urgent issue" in der Vorgangssuche unserer Test-Site abgelehnt (6. Okt. 2026).

Getestet auf einer echten Cloud-Site

Wir haben die ~-Abfrage ausgeführt, die laut Atlassian dem neuen = entspricht. Die Ergebnisse folgen den veröffentlichten Phrasenregeln, mit einer Ausnahme: Eine Phrase in Anführungszeichen wurde nicht auf den Wortstamm zurückgeführt. Die 12 Demo-Arbeitselemente mit dem Label jql-phrase-demo haben diese Zusammenfassungen: „Urgent“, „Urgent issue“, „Very urgent issue“, „URGENT ISSUE in production“, „Issue urgent“, „Urgent customer issue“, „Not urgent“, „Urgently needed: VPN access“, „Server running out of memory“, „Alpha beta release notes“, „Beta alpha rollback“ und „Alpha build for beta testers“.

Jeder Abfrage wurde labels = jql-phrase-demo AND vorangestellt:

Stemming: Laut Ankündigung entspricht das neue = der Suche ~ mit maskierten Anführungszeichen und führt gleichzeitig weiterhin Stemming durch. Auf unserer Site widersprechen sich diese beiden Aussagen: Das zitierte ~ "\"run\"" fand nichts, nur das nicht zitierte ~ "run" fand „running“. Auch Atlassians Artikel zur Phrasensuche sagt, dass eine Phrase keine Wortvarianten findet. Verlassen Sie sich auf keines der beiden Verhalten, bis Sie = auf Ihrer eigenen Site testen können.

"urgent" als Phrase: jede Zusammenfassung, die das Wort enthält, an beliebiger Stelle und in beliebiger Schreibweise.

"urgent issue": nur die beiden Wörter direkt hintereinander in dieser Reihenfolge. „Issue urgent“ und „Urgent customer issue“ fallen heraus.

Ohne maskierte Anführungszeichen findet ~ "alpha beta" die Wörter in beliebiger Reihenfolge (3 Elemente). Mit ihnen bleibt nur „Alpha beta release notes“ übrig.

Wo es kritisch wird

Am riskantesten sind die Stellen, auf die niemand schaut: Regeln und Skripte, die unbeaufsichtigt laufen und mit allem arbeiten, was die Abfrage zurückgibt.

• Gespeicherte Filter, Board-Filter, Dashboard-Gadgets. Ein = oder IN auf einem Textwert kann mehr Elemente zurückgeben, sodass Zählungen, Diagramme und Swimlanes wachsen. Geteilte Filter ändern sich für alle, die sie verwenden.
• Automatisierungsregeln. JQL-Bedingungen und Aktionen vom Typ „Lookup work items“, die = verwenden, treffen mehr Elemente, und die Regel bearbeitet, überführt oder benachrichtigt dann alle davon.
• NOT IN als Ausschlussliste. Es blendet nicht mehr einen exakten Wert aus, sondern jedes Element, das die Phrase enthält. Die gleichwertige !~-Abfrage auf unserer Site schloss auch „Not urgent“ aus (Screenshot unten).
• Skripte und Apps, die die REST-API aufrufen. Auf unseren Sites antwortete POST /rest/api/3/search/jql bei summary = "…" mit HTTP 200 und einer leeren issues-Liste, ohne Fehler oder Warnung, während die Vorgangssuche in der Oberfläche den Fehler anzeigte. Ein Skript, das vor dem Anlegen eines Elements nach summary = "<marker>" sucht, findet es deshalb nie und legt jedes Mal ein Duplikat an. Wenn = auf diesem Feld zur Phrasensuche wird, kann dieselbe Suche stattdessen „Nightly build 2“ für „Nightly build“ zurückgeben. Prüfen Sie generiertes JQL mit POST /rest/api/3/jql/parse?validation=strict und vergleichen Sie den zurückgegebenen Wert im Code exakt.

Das Äquivalent zu NOT IN ("urgent") behält 5 von 12 Elementen. „Not urgent“ und alle anderen Elemente, die das Wort enthalten, werden ausgeschlossen; „Urgently needed“ bleibt, weil eine Phrase keine anderen Wortformen findet.

So prüfen Sie Ihre Site

Beginnen Sie mit den gespeicherten Filtern: Gadgets, Boards und manche Automatisierungsregeln basieren darauf. Das folgende Skript listet jeden gespeicherten Filter auf, der =, !=, IN oder NOT IN auf einem Feld mit Zeichenkettenwert verwendet, und zur Sicherheit zusätzlich Summary und die anderen Standard-Textfelder. Es liest die Feldliste von Ihrer eigenen Site, sodass auch Felder von Apps erfasst werden.

1. Öffnen Sie Ihre Jira-Site im Browser mit einem Benutzer, der die globale Berechtigung „Jira verwalten“ hat. Das Skript übergibt overrideSharePermissions=true und sieht daher jeden Filter, nicht nur die mit Ihnen geteilten.
2. Öffnen Sie die Entwicklerkonsole (F12 → Console), fügen Sie das Skript ein und drücken Sie Enter.
3. Prüfen Sie jede ausgegebene Zeile: clause zeigt Feld und Operator, jql die vollständige Abfrage. Rechnen Sie mit einigen Fehlalarmen: Schlüsselwortartige Zeichenkettenfelder, die = akzeptieren, sind möglicherweise nicht betroffen.

// Paste into the browser console on https://<your-site>.atlassian.net
(async () => {
  const ac = await (await fetch('/rest/api/3/jql/autocompletedata')).json();
  const fields = ac.visibleFieldNames.filter(f =>
    (f.types || []).includes('java.lang.String') &&
    !f.value.endsWith('.property') &&
    f.operators.some(op => ['=', '!=', 'in', 'not in'].includes(op)));
  const names = new Set(['summary', 'description', 'environment', 'comment', 'text', 'textfields']);
  fields.forEach(f => {
    names.add(f.value.replace(/^"|"$/g, '').toLowerCase());
    if (f.cfid) names.add(f.cfid.toLowerCase());
  });
  const esc = s => s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
  const re = new RegExp('(?:^|[\\s(])"?(' + [...names].map(esc).join('|') +
    ')"?\\s*(!=|=|not\\s+in\\b|in\\b)', 'i');
  const hits = [];
  for (let startAt = 0, last = false; !last;) {
    const page = await (await fetch('/rest/api/3/filter/search?expand=jql,owner' +
      `&overrideSharePermissions=true&maxResults=100&startAt=${startAt}`)).json();
    page.values.forEach(f => {
      const m = (f.jql || '').match(re);
      if (m) hits.push({ id: f.id, name: f.name, owner: f.owner?.displayName,
                         clause: m[0].trim(), jql: f.jql });
    });
    last = page.isLast; startAt += page.maxResults;
  }
  console.table(hits);
  return hits;
})();

Auf unserer Test-Site markierte es den einen Demo-Filter, der "Project overview key" = "SK" verwendet, und übersprang den Filter mit ~. Das Skript ruft nur GET-Endpunkte auf.

Prüfen Sie danach, was das Skript nicht sehen kann:

• Automatisierung: Exportieren Sie Ihre Regeln unter Einstellungen → System → Globale Automatisierung als JSON. Anführungszeichen im JQL sind dort maskiert; suchen Sie daher ohne Beachtung der Groß-/Kleinschreibung mit einem regulären Ausdruck wie (=|!=|\bin\b|\bnot in\b) neben den Namen Ihrer Textfelder.
• Eigene Skripte und Apps: Durchsuchen Sie den Code nach JQL, das = oder IN auf Textwerten verwendet, und prüfen Sie es mit dem oben genannten Parse-Endpunkt.
• Geteilte Dashboards: Notieren Sie jetzt die Zählungen Ihrer meistgenutzten Gadgets, damit Sie vergleichen können, sobald die Änderung Ihre Site erreicht.

Spickzettel zum Umschreiben

Wählen Sie den Operator danach, was Sie meinen, nicht aus Gewohnheit. Die ersten fünf Zeilen liefen auf unserer Test-Site genau so wie angegeben.

Wenn Sie einen Wert immer exakt abgleichen müssen, speichern Sie ihn in einem Feld, das dafür gedacht ist: einer Auswahlliste, Labels oder einer Komponente.

FAQ

Muss ich jetzt sofort etwas ändern? Nur wenn ein Filter, eine Regel oder ein Skript darauf angewiesen ist, dass =, IN oder NOT IN auf einem Textwert nur exakte Übereinstimmungen des gesamten Werts liefert. Führen Sie die Prüfung durch und schreiben Sie die Abfragen dann mithilfe des Spickzettels um, damit die Absicht eindeutig ist.

Ist ~ betroffen? Die Ankündigung ändert daran nichts. ~ mit und ohne maskierte Anführungszeichen ist genau die Referenz, mit der Atlassian das neue = beschreibt.

Quellen

• Atlassian Developer Changelog, CHANGE-3440
• JQL-Operatoren (Jira Cloud)
• JQL-Feldreferenz (Jira Cloud)
• Search for an exact phrase with JQL (Atlassian Community)