-----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-----