v34.1 SSP - Ticket List Filter - Teams ausblenden

[AndreasU]

Hi,
wie kann ich im SSP im neuen Ticket List Filter bestimmte Felder ausblenden? Primär geht es uns um den Punkt Teams, der allen Usern im SSP unsere kompletten Teams anzeigt. Wenn das nicht einfach möglich ist, wie kann der Filter erst einmal komplett ausgeblendet werden?

VG
Andreas

[mplan]

Hallo,

möchte mich an die Frage mit anhängen.
Im SSP werden alle Teams im Filter angezeigt, auch solche, auf die noch nicht einmal alle Agents Zugriff haben. Im SSP sollten diese erst recht nicht erscheinen.

Es wäre schön, wenn diese Ansicht besser gesteuert oder  - wie angesprochen - erst einmal komplett ausgeblendet werden könnte.

Viele Grüße
Michael

[Torsten Thau]

Hallo,

leider kollidieren hier die Anwendungsszenarios einiger SSP-Nutzerkreise. Die Ticketsuche wurde mit hohem Druck eingefordert und dabei sollte auch alle im SSP sichtbaren Attribute suchbar sein. Das wurde geliefert. Leider passt das nicht in alle Anwendungsfälle. Danke für die Rückmeldung dazu.

Also gehen wir die nächste Evolutionsstufe an und nehmen mit, dass es schon aus UI/UX Sicht hilfreich wäre nur die Queues/Teams als Suchparameter aufzuführen in denen sich auch Tickets des SSP-Nutzers finden. Das macht das ganze für den Anwender übersichtlicher und erzeugt auch keine Widersprüche der Form "Kunde darf von Queue nichts wissen, aber sein Ticket liegt da und er soll wissen wo es liegt".

Eine allg. Anmerkung zu Sichtbarkeiten: SSP- und Agentennutzer haben wenig miteinander zu tun. Wenn es "geheime" Teams/Queues gibt, muss deren Sichtbarkeit für beide Nutzungskontexte über das jeweilige Berechtigungsschema beschränkt werden. Dabei ist unerheblich ob nicht einmal alle Agents Zugriff haben. Es ist nicht ungewöhnlich, dass Kunden mehr/andere Informationen haben als einige Agentenrollen und gilt auch umgekehrt. Das aktuelle Verhalten ist bereits bekannt aus "CustomerUserGroups" in KIX17.


VG, Torsten

[mplan]

Hi Torsten,

es ist schon klar, dass SSP- und Agent-Nutzer unterschiedlich sind. Bei uns greifen die Kunden auf das SSP zu.
Für die ist es m.E. uninteressant, in welchem Team das Ticket liegt. Wichtig ist, dass sie ihre Tickets finden.

Die angezeigten Informationen sind also die "externen" Informationen und Agents haben eine interne Sicht. Wenn es woanders anders herum ist, dann erhöht das natürlich den Aufwand als gegensätzliches Szenario.
Allerdings sollten die Sichten im Filter deshalb umso mehr konfigurierbar gestaltet werden für den Admin.

Interessant für die Kunden könnte eine Tagging von Tickets sein, so dass sie Tickets mit eigenen Tags (oder einer zentralen Tag-Liste) versehen können. Damit schweifen wir aber ab.

Was ich sagen wollte ist, dass die Sicht auf Queues für Agents gut eingestellt werden und man Queues ausblenden kann.
Diese Beschränkung habe ich aber nicht für die SSP Nutzer gesehen, die eigentlich nur Rechte auf die Tickets von sich selbst bzw. der Organisation haben. 
Im SSP-Filter sind alle Teams enthalten, die es gibt und auf die der SSP Nutzer keinen Zugriff hat bzw. haben sollte.
Ich möchte eigentlich nicht die interne Struktur so nach außen geben.
Deshalb sollte man die Filterung nach Teams mindestens optional gestalten und wenigstens auf die Teams beschränken, in denen Tickets der Organisation liegen.

Was ist gemeint mit
 "Wenn es "geheime" Teams/Queues gibt, muss deren Sichtbarkeit für beide Nutzungskontexte über das jeweilige Berechtigungsschema beschränkt werden." ?
Wie kann man für SSP Nutzer die Sicht auf die Teams im Filter beschränken? (es geht mir nicht um die Sichtbarkeit von Artikeln für das SSP).
Wie ist dein Satz verstehen?

Viele Grüße
Michael

[Torsten Thau]

Hallo,

ist nichts BEsonderes: mein Vorschlag wäre nur den Zugriff der Rolle "Customer" auf die Ressource "/system/ticket/queues" einzuschränken. Wenn alle Teams/Queues "geheim" sein sollen, dann würde das Beispiel im Anhang schon reichen. Sollen bestimmte Queues/Teams verfügbar sein sollen, bedarf es natürlich genauerer Angaben.

Die Ticketerstellung in spez. Queues via Vorlagen ist dann ggf. nicht möglich bzw. erzeugt Fehlermeldungen.

CU, Torsten

[AndreasU]

Hi,

sowas ähnliches hatte ich gestern schon getestet, bin aber nicht zum Erfolg gekommen. Hatte mehrere Varianten des Pfades für die Ressource ausprobiert, genau deine hatte ich nicht probiert. Danke, funktioniert erst mal soweit für uns.

VG
Andreas