Meelogic Atlassian Blog

Jira Vorschau 8.10

✓ OAuth 2.0-Unterstützung für eingehende E-Mails.

✓ Anzeigen der benutzerdefinierten Felder, deren Indizierung am längsten dauert

✓ Verbesserte Indizierung benutzerdefinierter Felder

✓ Automatische Entfernung veralteter Nodes

✓ Verbesserungen bei der Anonymisierung der User (DSGVO)

✓ Anonymisierung gelöschter User

✓ REST-API-Änderungen

✓ Implementierung der Validierungslogik

 

Übersicht der Änderungen

Hier informieren wir Sie über die Änderungen, die Atlassian in Jira 8.10 vornehmen wird. So können Sie sich vor einem Update Gedanken darüber machen, inwiefern diese Änderungen Auswirkungen auf Ihre aktuelle Jira-Konfiguration haben.


OAuth 2.0-Unterstützung für eingehende E-Mails.

Status: DURCHFÜHRUNG (eap 02)

Als Antwort auf die Ablehnung der Basic Authentication durch Google und Microsoft fügt Atlassian OAuth 2.0-Authentifizierungsmethoden für eingehende E-Mails hinzu (bisher unter Verwendung der Protokolle IMAP und POP3). Außerdem wird eine Rückportierung auf die unterstützten Enterprise-Versionen vorgenommen. Wenn Sie derzeit E-Mail zur Erstellung von Problemen und Kommentaren verwenden, müssen Sie die Einstellungen für eingehende E-Mails neu konfigurieren.

Die Unterstützung von OAuth 2.0 bedeutet eine Änderung der Posteingangseinstellungen und der Art und Weise, wie Sie den Posteingangsserver konfigurieren.


Anzeigen der benutzerdefinierten Felder, deren Indizierung am längsten dauert DATA CENTER

Status: IMPLEMENTIERT (eap 01)

Wenn Sie eine plötzliche Abnahme der Indizierungsleistung feststellen, kann dies daran liegen, dass ein benutzerdefiniertes Feld lange zum Indizieren braucht. Normalerweise ist die Zeit für die Neuindizierung nicht gleichmäßig verteilt und es gibt mehrere Felder, die den größten Teil der Indizierungszeit in Anspruch nehmen. Dies kann eine Herausforderung sein, insbesondere bei der Skalierung.

Anstatt die Protokolle für die Statistiken zu überprüfen, können Sie sie jetzt in Jira einsehen. Klicken Sie auf Actions > Custom field indexing für einen bestimmten Node, um die Daten anzuzeigen und Maßnahmen zur Verbesserung der Leistung zu ergreifen.

Mit diesem Report können Sie Ihre Data Center Apps und die von ihnen hinzugefügten benutzerdefinierten Felder testen, um zu sehen, welche Auswirkungen sie bei der Jira-Indizierung haben.


Verbesserte Indizierung benutzerdefinierter Felder DATA CENTER

Status: IMPLEMENTIERT (eap 02)

Eine große Anzahl von benutzerdefinierten Feldern kann sich negativ auf die Leistung und die Indexierungszeit in Jira auswirken. Um diese Auswirkungen zu minimieren, hat Atlassian eine neue Optimierung eingeführt, die die Anzahl der aufgerufenen Feldindizierer reduziert.

Jetzt werden Sortiermarkierungen für benutzerdefinierte Felder nicht mehr gespeichert, wenn für ein spezielles Problem keine entsprechenden Werte vorhanden sind.  Außerdem, werden Indizierer nur dann ausgeführt, wenn die Werte benutzerdefinierter Felder für ein bestimmtes Problem existieren und das benutzerdefinierte Feld sichtbar ist und diesem Problem ein Anwendungsbereich zugewiesen wurde.

Bislang betreffen all diese Verbesserungen nur die in Jira integrierten benutzerdefinierten Felder. Atlassian bietet auch eine experimentelle API, mit deren Hilfe Sie diese Verbesserungen nutzen können (weitere Einzelheiten dazu werden in Kürze in der Entwickler-Community veröffentlicht).

Dies ist eine komplexe Änderung der Kernfunktionalität von Jira. Falls Sie ein unerwartetes Verhalten im Bereich der benutzerdefinierten Felder beobachten, wenden Sie sich an den Kundensupport und/oder deaktivieren Sie diese Funktionalität über die Systemeigenschaften (jira.cfv.driven.indexing.disabled, jira.local.context.indexing.disabled, jira.skip.indexing.null.disabled).


Veraltete Nodes automatisch entfernt DATA CENTER

Status: IMPLEMENTIERT (eap 02)

Jetzt müssen Sie veraltete Nodes nicht mehr manuell entfernen. Nodes, die zwei Tage lang keine Aktivität zeigen, werden automatisch nach offline verschoben, und diejenigen, die offline sind, werden nach zwei Tagen aus dem Cluster entfernt.


Verbesserungen bei der Anonymisierung der User (DSGVO)

Status: IMPLEMENTIERT (eap 02)

Erweiterung des Umfangs der Anonymisierung

Die ursprüngliche Anonymisierung der User war mit einigen Einschränkungen verbunden, die in neueren Versionen weiterhin korrigiert werden. In Jira 8.10 werden Sie in der Lage sein, die folgenden Punkte zu anonymisieren:

  • Erwähnungen in der Vorgangshistorie
  • Erwähnungen in der Projektbeschreibung
  • Reporter und Ersteller von Vorgangssammlern
  • Vollständiger Name in der Vorgangshistorie (Bearbeiter, Autor, Einzel- und Multi-User-Picker)
  • Standardwert für Erwähnungen in benutzerdefinierten Textfeldern


Anonymisierung gelöschter User

Bisher war es nicht möglich, bereits gelöschte User zu anonymisieren, da Jira deren gelöschten Usernamen nicht in einen für die Anonymisierung benötigten User Key umwandeln konnte. Das ist jetzt behoben. Sie können gelöschte User anonymisieren, indem Sie zu Administration > User Management > Anonymization gehen und den Usernamen eingeben.

Wenn Sie einen gelöschten User anonymisiert haben, sehen Sie die gelöschte Bezeichnung neben seinem Benutzernamen. Ihnen fehlen auch einige zusätzliche Informationen, wie E-Mail-Adresse, Profil-Link oder der vollständige Name.


REST-API-Änderungen

Um die Anonymisierung von gelöschten User zu ermöglichen, hat Atlassian die folgenden Änderungen an der REST-API eingeführt:

  • Der Parameter include Deleted wurde der Abfrage get user hinzugefügt. Dies erlaubt es, gelöschte User zurückzuholen, und kann nur von Jira-Administratoren verwendet werden.
  • Das deleted Feld wurde zu der von dieser Abfrage zurückgegebenen Antwort hinzugefügt.

Die get user-Abfrage sollte genauso funktionieren wie vor den Änderungen – das neue gelöschte Feld wird verfügbar sein, aber der Rest der Antwort wird sich nicht ändern.

Die folgende Änderung wird auch der Java-API hinzugefügt:

/**

 * Checks if given user is deleted user.
 * Deleted user exists in jira app_users DB table (has user key and username) but does not exist in crowd (no user data eg. Full name, email etc.).
 *
 * @param user possible deleted user object - i.e. received from {@link #getUserByKeyEvenWhenUnknown(String)} or {@link #getUserByNameEvenWhenUnknown(String)}
 * @return <code>true</code> if given user is user existing in app_users DB table but does not exist in crowd, <code>false</code> otherwise (also when given object is <code>null</code>)
 * @see #getUserByKeyEvenWhenUnknown(String)
 * @see #getUserByNameEvenWhenUnknown(String)
 * @since 8.10
 */
@ExperimentalApi
boolean isUserDeleted(@Nullable ApplicationUser user);


Implementierung der Validierungslogik

Wenn ein User anonymisiert werden soll, führt Jira einige Validierungen durch – so kann überprüft werden, ob der User aktiv ist oder kein Systemadministrator ist. Als Anwendungsentwickler müssen Sie unter Umständen zusätzliche Prüfungen durchführen, beispielsweise um festzustellen, ob der Ziel-User für die Eigentumsübertragung die richtige Rolle hat.

Bis jetzt konnten Sie für diese Prüfungen außer der Anzeige der Protokolle oder der REST-API-Antworten nicht wirklich Fehlermeldungen erhalten.

Atlassian hat eine neue Methode implementiert, die es ermöglicht, eine Validierungslogik zu implementieren und Fehler zurückzugeben, falls diese fehlschlägt. Sie wird ausgeführt, bevor die Anonymisierung beginnt, so dass der Ausführende die Probleme schnell beheben und es erneut versuchen kann, bevor Änderungen vorgenommen werden.

Die Methode wurde in die com.atlassian.Jira.user.anonymize.AnonymizationHandler interface hinzugefügt:

/**
* Allows handlers to prevent the anonymization if it would break business logic constraints.
* <p>
* As an example, ownership transfer handler can ensure that an entity can only be transferred to
* a user with a particular role, e.g. only to another admin.
* <p>
* <strong>The calculations done here should be as quick as possible not to degrade the user experience!</strong>
* Only business logic constraints should be checked here. You can assume that the passed in parameters are otherwise
* valid, e.g. the user to transfer the entity to exists and is not disabled.
*
* @return an {@link ErrorCollection}, containing <strong>translated</strong> business logic validation errors if there were any, null otherwise
*
* @since v8.10
*/
@ExperimentalSpi
default ErrorCollection validateBusinessLogic(AnonymizationParameters anonymizationParameters) {
  return ErrorCollections.empty();
}