Freetext-Felder automatisch füllen

[ProfHastig]

Hallo OTRS-Gemeinde,
ich schon wieder. ..
Es gibt jetzt eine ganz besondere Anforderung, die darauf abzielt, Auswertungen/Statistiken der Tickets nach Inhalten aus der Customeruser Tabelle zu fahren.
Mein erster Ansatz war jetzt einfach die Suchmaske zu erweitern und dieses Felder dort mitaufzunehmen, leider greift die abgesetzte Query allerdings nur auf Felder innerhalb der Ticekt und Article-Tabelle. Aber vielleicht habe ich ja auch was übersehen.

Mein zweiter Ansatz würde deshalb das Problem so lösen, dass die Informationen aus der customeruser in die freetext-Felder bei der Ticketerstellung geschoben werden. Dazu müßte allerdings das ticket Modul entsprechend angepasst werden.

Hat hier jemand Erfahrtung dabei, oder sonst noch eine Lösung für das Problem?

[Joyner]

Hallo,

Freitext-Felder kannst du z.B., sofern die Tickets vom Kunde via E-Mail eintreffen, mittels PostmasterFilter füllen.

So qualifizieren wir bei uns Tickets zunächst global, und anschließend ggf. tiefergehend pro Queue.
Kann man auch "weiterspinnen" nach Keywords oder Usern...

mfg
Sebastian

[ProfHastig]

Hallo Sebastian,
für ankommende Requests per Email ist das sicher eine gute Lösung, die Tickets werden bei uns aber von Hand erfasst.
Mangels anderer Lösungen habe ich mich deshalb entschlossen die ticket.pm ein bisschen zu erweitern und die Zusatzinfos direkt hier zu ergänzen.
Hier die Erweiterung ab Zeile 500:

Code: Select all

		if ( $Param{CustomerUser} ) {
			my $SQL = 'SELECT department, cost_center, location, email, last_name from customer_user'
			        . ' WHERE  login = ?';
			$Self->{DBObject}->Prepare( SQL => $SQL, Bind => [ \$Param{CustomerUser} ] );

			while ( my @Row = $Self->{DBObject}->FetchrowArray() ) {
				my $department   = '';
			    my $costcenter = '';
			    my $location = '';
			    my $email = '';
			    my $lastname = '';
				$department   = $Row[0];
				$costcenter   = $Row[1];
				$location     = $Row[2];
				$email        = $Row[3];
				$lastname    = $Row[4];
			# set free text counter 16 = department
					$Self->TicketFreeTextSet(
					Counter => 16,
					Value => $department,
					TicketID => $TicketID,
					UserID => $Param{UserID},
			); 
			# set free text counter 15 = costcenter
					$Self->TicketFreeTextSet(
					Counter => 15,
					Value => $costcenter,  
					TicketID => $TicketID,
					UserID => $Param{UserID},
			); 

Geht für die anderen Felder dann noch weiter, würde hier aber zu weit führen.
Ist natürlich ein Hack der uns beim nächsten Upgrade wieder um die Ohren fliegt aber momentan geht's ganz gut und ich kann auch die Statistiken durch eine Erweiterung in den CustomFreeTextKeys ganz gut abgreifen.

[Joyner]

Hallo,

für händisch erfasste Tickets gebe ich einen Inhalt vor. Über ACL's, als eigentlich simples if-else, werden Ticketstati und Actions freigeben oder eben geblockt/ausgeblendet.

und btw...ihr habt bei euch "costcenter" erfasst. Wie gebt ihr den Wert vor? Beim Anlegen des Kunden in DB oder via LDAP gezogen?

Bei uns stellt sich das Problem, das ein Kunde, wir ziehen alle via LDAP, mehrere Kostenstellen haben kann, weil in mehreren Firmen und/oder Abteilungen.
Hab dazu ein costcenter-Modul geschrieben, bei dem ich pro Kunde mehrere Kostenstellen in einem Freitextfeld hinterlegen kann.
Wird nun ein Ticket erstellt (händisch), werden nur die exakt dem Kunden zugewiesenen Kostenstellen zur Auswahl angezeigt. Bei E-Mail-Tickets muss das, sofern mehrere zur Auswahl stehen, nachträglich erfasst werden.

Manko dabei...
Die Kostenstellen der Kunden werden, da die Daten ja "on demand" per LDAP gezogen werden, in einer zusätzlichen Tabelle erfasst und die Authentifizierung über ein "Login-Mailadresse-String" vollzogen...ändert sich der Login oder die Mailaddy, sind die Daten erstmal nicht vorhanden.
Wie ist das bei euch gelöst?

mfg
Sebastian

[ProfHastig]

wir haben keine LDAP-Anbindung, die Kostenstellen bzw. die restlichen Daten der User werden per csv import gezogen.
Die legen da eine Datei ab und ein Cronjob ruft ein Import-Perl Script auf, das die Daten dann importiert.
Bishere hatten wir auch noch nicht das Problem, das ein Customer mehrere Kostenstellen haben kann, aber dann wäre Deine Lösung bestimmt hilfreich.

Gruß