Data Protection and Security Toolkit 4.7.0 ist ein Zuverlässigkeits-Release

---

⚡ Ereignisgesteuerte Suchläufe starten ohne Wartezeit

Bisher teilten sich alle Suchtypen einen gemeinsamen Planungs-Pool. Ein lang laufender manueller, geplanter oder instanzweiter Suchlauf konnte sämtliche verfügbaren Slots belegen — Suchläufe, die durch Aktivität in Jira oder Confluence ausgelöst wurden, mussten warten.

Suchläufe bei Inhaltsänderungen laufen jetzt über einen eigenen Scheduler mit eigener Kapazität, getrennt vom und zusätzlich zum Haupt-Pool.

Das bedeutet in der Praxis: Wird ein Vorgang oder eine Seite bearbeitet, startet der zugehörige Suchlauf sofort — unabhängig davon, was sonst gerade auf der Instanz läuft. Am deutlichsten spürbar ist das auf stark genutzten Instanzen, auf denen regelmäßig geplante und instanzweite Suchläufe stattfinden.

---

📋 Zeilen pro Seite jetzt pro Benutzer einstellbar

Die Seitengröße war bisher eine einzige globale Einstellung, die für alle Personen mit Admin-Zugriff galt.

Sie wird jetzt pro Benutzer gesteuert. Jeder Admin legt seine eigene Seitengröße fest, die einheitlich in allen Listenansichten gilt.

Auch die Ignorierliste berücksichtigt diese Einstellung jetzt. Sie war zuvor unabhängig von der Konfiguration auf eine sehr kleine Seitengröße festgelegt, was die Arbeit mit längeren Ignorierlisten mühsam machte.

---

🕓 Vorlagen-Historie zeigt, warum ein Suchlauf gestartet wurde

Einträge in der Historie enthalten jetzt den Auslöser des jeweiligen Suchlaufs.

Bei Suchläufen, die durch Inhaltsänderungen ausgelöst wurden, zeigt die Historie zusätzlich den Titel des Jira-Vorgangs oder der Confluence-Seite, die den Lauf verursacht hat.

So lässt sich die Aktivität einer Vorlage auf einen Blick nachvollziehen — besonders auf Instanzen, auf denen manuelle, geplante und ereignisgesteuerte Suchläufe gegen dieselbe Vorlage laufen.

---

🔍 Eine neue, datenschutzbewusste Analytics-Grundlage

Die Produktanalyse läuft jetzt über PostHog — mit einem Modell, das gezielt auf die tatsächliche Nutzung der App zugeschnitten ist.

Drei Nutzungsgruppen werden strikt getrennt: Administratoren, die die App konfigurieren, Endanwender, die Ankündigungen ansehen, und die Suchaktivität auf Instanzebene. Jedes Ereignis wird dabei seiner Site zugeordnet, um Auswertungen auf Site-Ebene zu ermöglichen.

Beim Datenschutz haben wir besonders auf Folgendes geachtet:

• Analytics-Ereignisse laufen über unser Backend, sodass kein Analytics-Key in Ihrem Browser offenliegt.
• Fehlerdetails und personenbezogene Daten werden nie an die Analytics-Plattform übermittelt.
• Analytics lassen sich weiterhin vollständig über die bestehende Einstellung deaktivieren — jetzt schlicht mit „Analytics“ bezeichnet.

Das Ergebnis ist ein klareres Bild davon, welche Funktionen wirklich genutzt werden — und damit eine bessere Grundlage für unsere Priorisierung.

---

🛠️ Fehlerbehebungen und kleinere Verbesserungen

Zuverlässigkeit der Suche

• Suchläufe bei Inhaltsänderungen funktionieren jetzt auch auf hybriden Instanzen korrekt, auf denen sowohl Connect- als auch Forge-Komponenten laufen.
• Die Vorlagensuche in Confluence startet und stoppt jetzt in allen Instanzkonfigurationen zuverlässig.
• Änderungen, die die App selbst an Confluence-Inhalten vornimmt, lösen keine weiteren Suchläufe mehr aus — unnötige Wiederholungsläufe entfallen damit.
• Der instanzweite Suchlauf bricht nicht mehr ab, wenn er auf Jira-Kommentare trifft, deren Autor gelöscht oder deaktiviert wurde.

Confluence

• Schlüssel persönlicher Bereiche mit Zeichen wie @ . : - werden jetzt akzeptiert und nicht mehr als ungültig zurückgewiesen.
• Die Confluence-Administrationsseiten laden jetzt in allen Forge-Konfigurationen zuverlässig.

Benachrichtigungen und Bearbeitung

• Standard-SMTP-E-Mail-Benachrichtigungen werden jetzt korrekt versendet.
• Der Ankündigungs-Editor übernimmt Änderungen jetzt unmittelbar und fühlt sich dadurch spürbar flüssiger an.