Zugewiesene Assets im JSM-Portal für Nutzer sichtbar machen
In JSM-Assets liegen alle Geräte, Lizenzen und Verträge — aber Nutzer sehen selten, was auf ihren Namen läuft. Drei Wege das aufzulösen, mit ihren Trade-offs.
Ursprünglich von uns in der Atlassian Community (App Central) veröffentlicht.
Die Transparenz-Lücke
In vielen Organisationen werden in Jira Service Management und Assets strukturierte Inventare gepflegt:
- Laptops und mobile Geräte
- Software-Lizenzen
- Verträge
- Zugangsdaten
- Abonnements
- Sonstige Unternehmensressourcen
Aus IT-Sicht ist alles sauber erfasst. Aus Nutzersicht — oft eine Black Box. Endnutzer wissen typischerweise nicht:
- Welches Gerät genau auf ihren Namen registriert ist
- Welche Lizenzen sie gerade halten
- Wann etwas abläuft
- Wer offiziell als Besitzer eingetragen ist
Das ist die Lücke zwischen Daten-Verfügbarkeit und Daten-Transparenz. Folgen: wiederkehrende Support-Tickets, manuelle Recherchen der IT, Verzögerungen beim Offboarding, Reibung bei Audits, Verwirrung bei Verlängerungen, weniger Vertrauen in interne Prozesse.
Die zentrale Frage: Wenn Assets bereits strukturierte, verlässliche Daten enthält — warum bleiben diese vor den Personen versteckt, die sie beschreiben?
Option 1 — Automation + E-Mail
Mit Jira-Automation realisierbar:
- Nutzer (ID + E-Mail) per Webrequest senden abrufen — z. B. Get users from group.
- Über
{{webResponse.body.values}}verzweigen. - Pro Nutzer Objekte suchen mit AQL:
objectType = Laptops AND Owner = {{user.accountid}}. - Zeitgesteuert per E-Mail an
{{user.emailAddress}}versenden.
Pro: Bordmittel, keine zusätzliche UI.
Contra: Webrequest + API-Token nötig, mehrere Schemas schwer abzudecken, keine kombinierte Übersicht in einer Mail, statische Daten, keine Echtzeit, E-Mails gehen verloren, keine Filterung auf Empfängerseite.
Als Übergangslösung brauchbar. Als Dauerlösung nicht ideal.
Option 2 — Assets direkt im JSM-Portal anzeigen
Eine Self-Service-Ansicht im Portal ersetzt den E-Mail-Loop. Wir haben das in unserer App Assets Gadgets for Jira (Dashboards & Reporting) umgesetzt.
In der Konfiguration legt man Schemas, Objekttypen und sichtbare Attribute fest. Filter ist eine kontrollierte AQL-Abfrage:
Owner = currentUser()
Bei verknüpften Objekten geht es eine Ebene tiefer:
"Owner"."Atlassian Account ID" = currentUser()
Garantien:
- Nutzer erhalten keinen Zugriff auf das ganze Schema
- Nutzer können keine freien AQL-Abfragen ausführen
- Filterung auf Anwendungsebene —
currentUser()wird serverseitig ersetzt - Transparenz, ohne das Zugriffsmodell zu umgehen
In unserem Einsatz rendert das Gadget einen Bereich „My Assets" im JSM-Portal. Mehrere Schemas, unterschiedliche AQL-Filter pro Schema und explizite Spaltenauswahl werden unterstützt.
Pro: schnelles Setup, mehrere Schemas + Objekttypen, keine Webhooks oder Tokens nötig, Echtzeit-Updates.
Ziel ist nicht „alles offenlegen" — sondern Support-Last reduzieren und Assets von einer internen IT-Datenbank zu einer transparenten Self-Service-Schicht machen.
Option 3 — Assets in das Antragsformular einbetten
Assets-Felder mit dynamischem AQL direkt im Antragsformular. Nützlich, wenn das Asset im Moment der Ticket-Erstellung gebraucht wird — z. B. „defekten Laptop melden, eigenen aus der Liste wählen".
Liefert keine allgemeine Übersicht über zugewiesene Objekte; ergänzt Option 1 oder 2, ersetzt sie nicht.
Welche Option passt?
Drei ehrliche Antworten je nach Kontext:
- Reaktiv — im Antragsformular einbetten (Option 3), wenn Assets nur zur Ticket-Erstellung relevant sind.
- Periodisch — Automation + E-Mail (Option 1), wenn kein Portal-Anpassungs-Budget vorhanden ist.
- Immer verfügbar — im Portal rendern (Option 2), wenn ihr keine Tickets der Art „Was steht auf meinem Namen?" mehr wollt.
Wie löst ihr das in eurer Organisation? Schreibt uns gern über Support.