Alles, was die App tut, vom Wert auf dem Bildschirm des Kunden bis zu den Einstellungen, die darüber entscheiden. Was der Kunde sieht, ist entsprechend gekennzeichnet; alles andere ist für Administratoren.
Auf der Anfrageseite
Das Panel sitzt in der rechten Spalte der Anfragedetailseite, unter Status und Anfragetyp. Es zeigt nur die von Ihnen konfigurierten Felder und nur bei Anfragen, in denen sie einen Wert haben.
Jeder Wert wird für die Person formatiert, die ihn liest, in ihrer Sprache und Zeitzone.
Die Seitenleiste des Portals ist schmal. Markieren Sie ein Feld für lange Werte, dann zeigt das Panel eine kurze Vorschau mit der Schaltfläche Vollständigen Text anzeigen statt einer Spalte umbrochener Wörter. Eine Einstellung pro Feld.
Bearbeitung im Portal
Nach der Installation und nach jedem Upgrade ist die Bearbeitung ausgeschaltet. Ein Feld wird erst bearbeitbar, wenn ein Administrator es einschaltet, und auch dann entscheidet Jira, was es akzeptiert.
Eine Auswahlliste mit genau den Optionen, die Jira für diese Anfrage anbietet, eine Datumsauswahl für ein Datum, ein Suchdialog für ein Assets-Objekt, ein Textfeld für Text. Ein langes Feld öffnet einen größeren Editor in einem Dialog.
Ein kurzer Hinweis pro Feld sagt dem Kunden, was dort hineingehört, übersetzbar wie die Bezeichnung. Ein als Pflichtfeld markiertes Feld lässt sich nicht leer speichern.
Einmal pro Konfiguration festgelegt, gilt es für jedes bearbeitbare Feld darin.
Jira akzeptiert eine Änderung nur, wenn das Feld auf dem Bearbeitungsbildschirm des Projekts liegt und die App dort Vorgänge bearbeiten darf. Die Einstellungsseite kann das nicht im Voraus wissen, deshalb fragt sie nach.
Sie legen welche Felder pro Feld fest, wer und bis wann pro Konfiguration. Die Einstellungsseite erinnert Sie daran, dass Jira weiterhin mitentscheidet und sein Vorgangsverlauf die App nennen wird.
Mit der Änderung wird der Wert mitgeschickt, den der Kunde gesehen hat. Hat ein Agent das Feld in der Zwischenzeit bearbeitet, wird das Speichern des Kunden abgelehnt, und er wird gebeten, die Seite neu zu laden. Ein abgelehntes Speichern ist einem stillen Überschreiben immer vorzuziehen.
Assets-Objekte
Die Vorgangs-API von Jira liefert ein Assets-Feld (CMDB) nur als Kennungen. Deshalb zeigen Portale es meist leer oder als Nummer an. Die App schlägt den Namen des Objekts nach und zeigt diesen an.
Das bereits mit der Anfrage verknüpfte Objekt erscheint mit seinem Namen. Dieser wird beim Aufruf der Anfrage aus Assets gelesen und nicht gespeichert.
Ein Suchdialog, beschränkt auf die Objekttypen, die Sie für dieses Feld erlaubt haben. Ist kein Typ erlaubt, findet die Suche gar nichts, also auch nicht alles.
Assets ist Bestandteil von JSM Premium. Auf einer Site ohne Assets gibt es keine Assets-Felder anzuzeigen, und die Assets-Berechtigungen der App werden nie genutzt.
Felder auswählen
Die Einstellungsseite listet jedes Feld Ihrer Site mit Name, Typ und ID. Wählen Sie eines aus, wird die Bezeichnung mit dem Namen aus Jira vorbelegt, den Sie ändern können.
Priorität, Fälligkeitsdatum, Komponenten, Versionen, Beschreibung und Lösung stehen in derselben Liste wie Ihre benutzerdefinierten Felder. Ein bereits gewähltes Feld wird in den anderen Zeilen ausgeblendet, damit nichts doppelt zugeordnet wird.
Zwei Arten werden unabhängig von der Konfiguration abgelehnt, auch beim Import: die Sicherheitsstufe, die eine Zugriffsregel ist und kein Wert, und Container wie Kommentare, Arbeitsprotokolle, Anhänge und Vorgangsverknüpfungen.
CF_ASSET_TAG_PRI sagt einem Kunden nichts. Seriennummer des Geräts schon. Jedes Feld erhält eine Anzeigebezeichnung, das Panel eine optionale Überschrift.
Pro Service-Desk
Eine Standardkonfiguration gilt überall. Jedes Serviceprojekt kann sie durch eigene Felder, Bezeichnungen und Bearbeitungsregeln ersetzen.
Ein Projekt ohne eigene Konfiguration verwendet den Standard. Eine Projektkonfiguration ersetzt den Standard für dieses Projekt, damit ein HR-Desk nie versehentlich ein IT-Feld zeigt.
Service-Desk-Verantwortliche ändern ihre Bezeichnungen und Felder selbst, ohne auf einen Site-Administrator zu warten. Die Seite erreicht nur ihr eigenes Projekt, bei jedem Aufruf auf dem Server erneut geprüft. Standardkonfiguration und Sprachen bleiben bei den Jira-Administratoren.
Sprachen
Die Oberfläche der App ist vollständig in 26 Sprachen übersetzt: jeder Text, in jeder Datei, automatisch geprüft. Sie folgt der Atlassian-Spracheinstellung jedes Betrachters und greift ersatzweise auf Englisch zurück.
Wählen Sie die Sprachen Ihrer Kunden und übersetzen Sie so viel, wie Sie möchten. Alles Unübersetzte erscheint in Ihrem Standardwortlaut. Entfernen Sie eine Sprache, verschwinden ihre Übersetzungen überall, damit niemand weiterhin Text sieht, den Sie für gelöscht halten.
Rollout, Diagnose & Protokolle
Die Werkzeuge, die ein Jira-Administrator braucht, sobald mehr als ein Team die App nutzt.
Kopieren Sie eine bewährte Konfiguration in einem Schritt auf beliebige ausgewählte Projekte. Exportieren Sie eine vollständige Konfiguration als Text und importieren Sie sie auf einer anderen Site, damit Staging und Produktion übereinstimmen.
Das Änderungsprotokoll hält fest, welcher Administrator welche Konfiguration geändert hat, die letzten 100 Änderungen. Änderungen durch Kunden hält fest, welcher Kunde welche Felder in welcher Anfrage geändert hat, die letzten 200, nur Feld-IDs, nie die Werte. Beide lassen sich jederzeit leeren.
Grenzen
| Grenze | Wert |
|---|---|
| Felder pro Konfiguration | 20 |
| Projektkonfigurationen | 50, zuzüglich des Standards |
| Überschrift, Bezeichnung, Hinweis, jede Übersetzung | 100 Zeichen |
| Sprachen | 26 |
| Text, den ein Kunde eingeben kann | 32.767 Zeichen, die Grenze von Jira selbst |
| Werte in einem Mehrfachwertfeld | 100 |
| Erlaubte Assets-Objekttypen pro Feld | 20 |
| Änderungsprotokoll / Kundenprotokoll | Letzte 100 / letzte 200 Einträge |
Zeigen Sie diese zuerst nur an. Geben Sie eines zur Bearbeitung frei, wenn Sie so weit sind. Bearbeitbar wird nichts, bevor Sie es einschalten.
Custom Fields for JSM Portal