Roles / Customers / Merge & der Rest
Hi,
ich evaluiere gerade OTRS (2.0.1 - Debian Experimental) im Hinblick auf
unsere Anforderungen. Wir versuchen gerade ein kommerzielles System (pain
in the ass) durch ein Uboot abzulösen, d.h. (noch) keine offizielle
Support Anfrage. Ich bin ein paarmal durch die Docu durch, aber mit fehlt
etwas der rote Faden scheint mir.
Soweit läuft alles gut, aber einige Funktionalitäten erschliessen sich mir
nicht so ganz:
Zur Installation:
================
Debian Packet muss sein. Zur Not (2.0.1 ist ja nicht das letzte Release)
würde ich die Patches per Hand in das SRC-DPKG einpflegen. Gibts eine
Möglichkeit an Patchsets zu kommen? Version: 2.0.1p01-1 Maintainer:
Torsten Werner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dirk, On Tue, Oct 11, 2005 at 06:26:12PM +0200, Dirk Vleugels wrote:
ich evaluiere gerade OTRS (2.0.1 - Debian Experimental) im Hinblick auf unsere Anforderungen. Wir versuchen gerade ein kommerzielles System (pain in the ass) durch ein Uboot abzulösen, d.h. (noch) keine offizielle Support Anfrage. Ich bin ein paarmal durch die Docu durch, aber mit fehlt etwas der rote Faden scheint mir.
Wenn du da Fehler findest oder was unklar ist, dann schreibe bitte einen Fehlerbericht auf http://bugs.otrs.org oder melde dich in der doc-de Liste. Ich kann's dann versuchen besser im Handbuch zu erklären oder ich baue weitere Kapitel / Abschnitte ein.
Debian Packet muss sein. Zur Not (2.0.1 ist ja nicht das letzte Release) würde ich die Patches per Hand in das SRC-DPKG einpflegen. Gibts eine Möglichkeit an Patchsets zu kommen? Version: 2.0.1p01-1 Maintainer: Torsten Werner
Du kannst über http://alioth.debian.org auf das pkg-otrs-Projekt bei debian zugreifen, einfach auf der Startseite mal nach OTRS suchen. Auf der Projekt Page selbst gibts IIRC die Möglichkeit per SubVersion an die Sourcen des Pakets zu kommen, evtl. gibts da auch die Möglichkeit Patches runterzuladen.
Ich habe CustomerGroupSupport enabled. Ich bin mir nicht sicher wie ich ohne CustomerGroups überhaupt mit Customern arbeiten sollte!?
In vielen einfacheren Installationen braucht man keine Kundengruppen. Kundengruppen werden eigentlich erst dann interessant, wenn verschiedene Kunden auf versch. Queues Zugriff haben sollen, ansonsten braucht man das eigentlich nicht.
Priorities habe ich umbenannt (lokaler Standard). TicketFreeText wird benutzt um die Tickets genauer zu klassifizieren. Die Felder tauchen auch (nach kleineren Template Änderungen) bei der Ticket Eröffnung auf (sowohl Customer als auch Agent Phone/Email). Man kann danach suchen etc.
Funktioniert alles soweit.
Gut :).
Wir haben den Fall das Agents auch Tickets aufmachen können sollen. Zur Zeit tendiere ich dazu jedem Agent auch einen Kunden mit dementsprechenden Rechten zu verpassen (separates Login). Ich habe den UseCase für Agent/Phone/Email Ticket noch nicht wirklich durchschaut glaube ich:
- PhoneTicket damit ein Kunde via Tel. ein Ticket beim Agent aufmachen kann, klar. Daher muss auch immer ein Kunde eingetragen werden.
Genau. Kunde ruft an, Agent trägt was zum Telefongespräch ein.
- EmailTicket? Von Queue nach Kunde?
Genau. Ein Agent will einen Kunden was schreiben und das soll in ein neues Ticket.
- Das Problem/Feature ist wohl das ein Agent kein Kunde ist.
Es gibt einen general Parameter, dass ein angelegter Agent auch gleichzeitig Kunde ist: # Ticket::AgentCanBeCustomer # (use this if an agent can also be a customer via the agent interface) $Self->{'Ticket::AgentCanBeCustomer'} = 1; Nur erklär bitte erst mal genauer was du vor hast, evtl. brauchst du das nämlich gar nicht.
Was übersehe ich hier? Wie implementiert ihr das?
Erkläre deine Anforderungen genauer..., dann können wir dir sicher besser weiter helfen.
Rollen: ======
Ich habe durchschaut wie die Benutzerverwaltung für 'Benutzer/Agents' mit Rollen abgebildet wird, allerdings weiss ich nicht wie ich das mit Kunden machen soll. Als Beispiel unsere Setup:
Wir haben drei Incoming Queues: A B C. An jeder incoming queue hängen noch drei Bearbeitungs-Queues (PROD, MIG, DEV). Das sind z.Z. Sub-queues, wobei ich den vorteil bei Sub-Queues gegenüber normalen Top-Level Queues nicht erkennen kann.
Einen wirklichen Vor- oder Nachteil in der Bearbeitung gibt es bei Sub- oder Haupt-Queues nicht. Die Vorteile liegen eher darin, dass du dein system besser Strukturieren kannst. Weiterhin kannst du auch über Zugriffsrechte Dinge besser abbilden oder eine Haupt-Queue auf einen Schlag deaktivieren, wodurch auch alle Sub-Queues inaktiv werden.
Für jede Queue existiert eine Gruppe: A B C
Agents/Dispatcher: haben move into PROD, MIG, DEV für die jeweilige source Queue.
Customer: haben 'create', für die source Queue (alle Tickets sehen sie über Company Tickets)
Ist das ok so? Würdet ihr das anders lösen?
Hmm, das kann man so auch schwer beantworten, weil ich deine genauen Anforderungen nicht kenne :(. Aber erst mal hört sich's OK an.
Ich spiele mit dem System erst knapp zwei Tage rum, d.h. sorry falls es doch ein paar RTFMs waren.
Passt schon :). OTRS ist komplex, man braucht etwas, bis man da rein kommt :).
Dirk
Ciao, Christian - -- ((otrs)) :: OTRS GmbH :: Europaring 4 :: D - 94315 Straubing Fon: +49 (0) 9421 1862 760 :: Fax: +49 (0) 9421 1862 769 http://www.otrs.com/ :: Communication with success! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDV+jNTFWOq90iSiERAnrfAKDJjs2YICF2dTwXLgao417XZf6cSQCgoXrQ MW08Utv0wI6g/+O0i0gIUeE= =col5 -----END PGP SIGNATURE-----
Hi Christian,
On 10/20/05, Christian Schoepplein
Wenn du da Fehler findest oder was unklar ist, dann schreibe bitte einen Fehlerbericht auf
oder melde dich in der doc-de Liste. Ich kann's dann versuchen besser im Handbuch zu erklären oder ich baue weitere Kapitel / Abschnitte ein.
Schwer einzuschätzen ob es an meinem mangelnden Durchblick liegt .-)
Ich habe CustomerGroupSupport enabled. Ich bin mir nicht sicher wie ich ohne CustomerGroups überhaupt mit Customern arbeiten sollte!?
In vielen einfacheren Installationen braucht man keine Kundengruppen. Kundengruppen werden eigentlich erst dann interessant, wenn verschiedene Kunden auf versch. Queues Zugriff haben sollen, ansonsten braucht man das eigentlich nicht.
In diesem Fall kann ein Kunde dann sein Ticket nicht verfolgen, da wir eine Art Workflow über mehrere Queues abgebildet habe (z.B. incoming -> projektleitung -> development -> qs -> ...). Sobald das Ticket 'incoming' verlässt kann der Kunde es nicht mehr sehen, und damit auch nicht den Status etc. verfolgen (Email Benachrichtigung wollen wir hier aus bestimmten Gründen nicht). Oder gibt es etwas wie $Self->{'Ticket::CreatorMayAlwaysSee'} = 1; welches read-only Rechte für dieses Ticket auf allen folge-queues simuliert?
- Das Problem/Feature ist wohl das ein Agent kein Kunde ist.
Es gibt einen general Parameter, dass ein angelegter Agent auch gleichzeitig Kunde ist:
# Ticket::AgentCanBeCustomer # (use this if an agent can also be a customer via the agent interface) $Self->{'Ticket::AgentCanBeCustomer'} = 1;
Das bedeutet aber wohl nicht das ich mit Agent Login via customer.pl reinkomme, oder? Ich kann dann auch nicht 'mich' als Agenten ins 'From' eines PhoneTickets packen. Was bringt diese Einstellung (ja, vorhandene Emails im Archive zu diesem Thema habe ich auch nicht verstanden .-) ?
Ich spiele mit dem System erst knapp zwei Tage rum, d.h. sorry falls es doch ein paar RTFMs waren.
Passt schon :). OTRS ist komplex, man braucht etwas, bis man da rein kommt :).
Ich habe nichts anderes erwartet :-) Danke für deine Zeit, Dirk
participants (2)
-
Christian Schoepplein -
Dirk Vleugels