Bulker Release Notes — September 2026: Bulk Rename für Jira-Schemes

Der September bringt Bulk Rename — Jira-Schemes, Screens und Filter in einem Durchgang umbenennen, mit Namensregel — und eine Scheme-Zuweisung, die meldet, was Jira wirklich tat.

Im September sind zwei Versionen erschienen: Bulker 6.1.0 am 10. September und Bulker 6.2.0 am 14. September. Zusammen bringen sie das gesammelte Umbenennen von Jira-Konfigurationsobjekten, sorgen dafür, dass Bulker beim Zuweisen von Schemes meldet, was Jira tatsächlich getan hat, beheben einen Freigabe-Fehler, der Zugriffe bestehen lassen konnte, und machen das Vorgangsprotokoll verlässlich.

Keine der beiden Versionen braucht neue Berechtigungen – auf den meisten Instanzen ist das Update deshalb schon von selbst angekommen. Unten: was Bulk Rename kann und wie ein Durchgang Schritt für Schritt abläuft, danach alles Weitere.

Bulk Rename — neu in 6.1.0

Jede Jira-Instanz, die schon eine Weile läuft, sammelt Schemes, die niemand mehr auseinanderhalten kann: „Default Notification Scheme", „Copy of Default Notification Scheme", „Simplified Scheme 2". Jedes Team hat Dinge anders benannt, und die Admin-Seiten werden zum Ratespiel. Jira selbst lässt euch Jira-Schemes gesammelt umbenennen nur Objekt für Objekt.

Der neue Rename-Tab erledigt das in einem Durchgang – und zwar nur für die Objekttypen, die Bulker über die öffentliche Jira-API sicher umbenennen kann:

• Issue type schemes
• Issue type screen schemes
• Notification schemes
• Issue security schemes
• Screens
• Screen schemes
• Permission schemes
• Filter

Jede Umbenennung sendet nur den neuen Namen und die eigene Beschreibung des Objekts – sonst wird nichts am Objekt verändert. Das ist vor allem bei Permission Schemes wichtig: Jira löscht die Beschreibung, wenn man nur den Namen schickt, deshalb sendet Bulker die Beschreibung immer unverändert mit.

Der Rename-Tab: Einstellungen links, Objekte rechts

Jira-Schemes gesammelt umbenennen – Schritt für Schritt

Schritt 1 – Objekttyp wählen

Öffnet Einstellungen → Apps → Bulker → Rename und wählt unter Object type einen Typ. Bulker lädt alle Objekte dieses Typs und zeigt Name, Länge und die Projekte, die sie verwenden.

Die Projektzuordnungen mancher Typen laden etwas länger. Solange sie nicht geladen sind, ist der Projektfilter deaktiviert und die Projektschlüssel-Regel bleibt aus – Bulker rät nicht, dass ein Objekt „in keinem Projekt" ist, nur weil Jira noch nicht gefragt wurde.

Schritt 2 – Objekte finden und anhaken

Grenzt die Liste rechts mit Search by name, Project und Policy ein und hakt die gewünschten Objekte an. Select page und Select all shown haken alles an, was die aktuellen Filter übrig lassen.

Die Zeile über der Tabelle zeigt immer, wie viele Objekte angehakt sind – und genau so viele werden umbenannt. Nichts anderes auf der Seite entscheidet darüber.

Schritt 3 – Die Änderung beschreiben

Die Karte Rename rule links bietet vier Regeln:

Bei Add the project key bekommt ein Objekt, das genau ein Projekt nutzt, dessen Schlüssel. Objekte, die mehrere oder gar keine Projekte nutzen, bekommen das von euch gesetzte Fallback-Token – zum Beispiel GLOBAL – oder bleiben außen vor, wenn das Token leer ist.

Lasst Skip objects that already match an, damit Namen, die bereits mit eurem Text beginnen, unverändert bleiben.

Schritt 4 – In der Vorschau bestätigen

Klickt auf Continue. Es öffnet sich ein Dialog mit der Anzahl im Titel – „Rename 2 issue type screen schemes?" – und einer Tabelle aller angehakten Objekte mit aktuellem und neuem Namen. Zeilen, die Bulker nicht umbenennen kann (Name zu lang, Name schon vergeben), sind mit dem Grund markiert, und Umbenennen bleibt aus, bis sie gelöst sind.

Klickt auf Rename, um den Durchgang zu starten. Das Ergebnis listet jedes Objekt mit Done oder Failed und dem Grund.

Eine Umbenennung rückgängig machen

Bulker merkt sich die vorherigen Namen. Nach einem Durchgang stellt Undo the last rename sie wieder her und meldet „Restored · Skipped · Failed".

HINWEIS: Objekte, die nach dem Durchgang erneut umbenannt wurden, bleiben unberührt – ein Undo überschreibt nie eine neuere Änderung. Ein Undo selbst lässt sich nicht rückgängig machen.

Namensregel festlegen und Abweichungen beheben

Eine Namensregel ist ein Muster, dem eure Namen folgen sollen – einmal für die ganze Instanz gespeichert. In der Karte Naming policy:

• {key} steht für einen der Projektschlüssel des Objekts
• {token} steht für das Fallback-Token
• * passt auf beliebige Zeichen

{key}: * bedeutet zum Beispiel „beginnt mit einem Projektschlüssel und einem Doppelpunkt". Bulker zeigt dann, wie viele Objekte off policy sind und wie viele Namen doppelt vorkommen, und der Policy-Filter über der Tabelle grenzt die Liste darauf ein.

Zwei Buttons machen aus der Regel konkrete Arbeit:

• Select the N off policy hakt genau die Objekte an, die nicht passen.
• Build a rule from this policy füllt die Umbenennungsregel darüber so aus, dass die Namen danach dem Muster entsprechen.

Danach geht es mit Schritt 4 weiter. Hat jemand zwischenzeitlich eine neuere Fassung der Regel gespeichert, überschreibt Bulker sie nicht, sondern zeigt, wer sie wann geändert hat.

Wenn Jira ablehnt

Manche Umbenennungen lehnt Jira selbst ab, und Bulker zeigt dann Jiras eigene Begründung statt eines allgemeinen Fehlers. Ein häufiger Fall sind Notification Schemes von team-managed Projekten: Jira erlaubt das Umbenennen nur bei company-managed Projekten. Filternamen sind pro Owner eindeutig, deshalb stellt sich erst beim Umbenennen heraus, ob ein Filtername schon vergeben ist.

Was sich in 6.2.0 geändert hat

Der Rename-Tab erschien in 6.1.0 und wurde vier Tage später überarbeitet.

• Einstellungen links, Objekte rechts. Objekttyp und Umbenennungsregel stehen in blauen Karten links, die Namensregel in einer grauen Karte darunter; Filter und Tabelle füllen die rechte Seite.
• Bestätigung, bevor sich etwas ändert. Continue öffnet den oben beschriebenen Dialog – und dort steht der einzige Button, der umbenennt.
• Nach Namensregel filtern. Ein Policy-Filter neben Project grenzt die Tabelle auf Objekte ein, die von der Regel abweichen, ihr entsprechen oder denselben Namen tragen.
• Ein Button, eine Aktion. Select the N off policy und Build a rule from this policy tun jeweils genau eine Sache.
• Eine Tabelle, die stillhält. Die Spalte Projects zeigt bis zu sechs Schlüssel plus „+N more", die vollständige Liste beim Überfahren, und Zeilen ändern beim Eintippen einer Regel nicht mehr ihre Höhe.
• Zuverlässig bei instabiler Verbindung. Bricht die Verbindung zu Jira mitten in einer Anfrage ab, wiederholt Bulker sie jetzt automatisch – so wie bisher schon bei Rate-Limits und vorübergehenden Jira-Fehlern – statt „Jira could not be read" anzuzeigen. Das gilt für jede Bulker-Operation, nicht nur fürs Umbenennen.

Scheme-Zuweisung, die meldet, was passiert ist

• Issue security schemes. Jira wendet sie im Hintergrund an. Bulker wartet jetzt, bis Jira fertig ist, und meldet das echte Ergebnis – bisher wurde eine erfolgreiche Zuweisung als Fehler protokolliert.
• Priority schemes. Nutzen Vorgänge eines Projekts Prioritäten, die das neue Scheme nicht enthält, ordnet Bulker sie der gleichnamigen Priorität im Ziel-Scheme zu, sonst dessen Standardpriorität. Jira hat solche Zuweisungen bisher komplett abgelehnt.
• Lang laufende Zuweisungen. Arbeitet Jira noch, wenn Bulkers Wartezeit endet, wird der Vorgang als in progress mit Jira-Task-Referenz gemeldet – die Zuweisung wurde also angenommen, nicht verloren.
• Field configuration schemes nutzen Jiras neuere Field-Schemes-Schnittstelle, wo eine Instanz sie hat, und greifen automatisch auf die bisherige zurück, wo sie noch nicht aktiviert ist.
• Gruppen in Projektrollen werden über die Gruppen-ID statt über den Namen gespeichert – das Umbenennen einer Gruppe wirkt sich nicht mehr auf die von Bulker vergebenen Rollen aus.

Fixes bei Freigaben und Rollen

• Das Entfernen einer Gruppenfreigabe für Filter oder Dashboards funktioniert jetzt immer. Bisher konnte ein Erfolg gemeldet werden, obwohl der Zugriff bestehen blieb. Eine Gruppe, die bereits Zugriff hat, wird nicht mehr doppelt hinzugefügt.
• Bulk Add Users/Groups zeigt Jiras tatsächlichen Grund, wenn jemand nicht hinzugefügt werden kann – etwa eine Tarifbeschränkung – statt immer „Actor may already be in this role", und der Name steht nicht mehr doppelt in der Meldung.

Ein Vorgangsprotokoll, auf das Verlass ist

• Ein großer Vorgang löscht nicht mehr die Historie. Jeder Vorgang speichert bis zu 25 detaillierte Fehler plus eine Zusammenfassungszeile, sodass frühere Einträge im Protokoll bleiben.
• Die Summen stimmen. Die Zusammenfassung lautet „Operations: total — succeeded, failed, still running", und Fehler werden auch dann gezählt, wenn ältere Einträge schon aus dem Protokoll herausgefallen sind.
• „In progress" wird aufgelöst. Vorgänge, die Jira noch anwendete, als Bulker aufhörte zu warten, werden bei jedem Öffnen von Bulker geprüft; ihre Zeile wechselt auf Done, Failed oder Unconfirmed, falls Jira den Task nicht mehr kennt.
• Jiras eigene Begründung erscheint jetzt neben dem Scheme-Namen, wenn Jira einen Vorgang ablehnt, statt einer rohen technischen Antwort.

So kommen die Updates auf die Instanz

Beide Versionen brauchen keine neuen Berechtigungen. Instanzen mit Bulker 6 haben sie automatisch erhalten. Auf Instanzen mit einer älteren Hauptversion wird das Update einmal unter Einstellungen → Apps → Apps verwalten bei Bulker bestätigt.

FAQ

Bulker ausprobieren

Bulker nimmt die repetitive Seite der Jira-Administration ab – Schemes, Rollen, Projektleitungen, Archivierung und jetzt auch gesammeltes Umbenennen. Mehr Wege, Admin-Kleinkram zu reduzieren, findet ihr in Jira-Bulk-Administration: So sparst du 3 Stunden pro Woche, und die vorherige Version in den Bulker Release Notes – Juli 2026.