[otrs-de] <OTRS_CUSTOMER_REALNAME> gleiche Variable, unterschiedlicher Output! (?)

[André Bauer]

Guten Tag Christian Schoepplein.

Der einzige Unterschied in meiner Defaults.pm, zu der aus dem OTRS
2.0.4 Tarball, ist folgender:

617c617
<     $Self->{'Home'} = '/opt/otrs';
---
>     $Self->{'Home'} = '/usr/share/otrs';

Ansonsten ist alles gleich.
[ 'UserEmail',      'Email',      'email',       0, 1, 'var', '', 0 ],
Ist also auch genau so vorhanden.

Kunden Benutzer haben wir nicht, da die Kunden nur über Mails mit uns
kommunizieren. <OTRS_CUSTOMER_From> sollte dann doch aber trotzdem
funktionieren, oder funktioniert das Ganze nur mit vorhandenen
Kundenbenutzern? Wenn ja, warum funktioniert dann
<OTRS_CUSTOMER_REALNAME> bei mir?


-- 
Mit freundlichen Grüssen
André Bauer
System: Debian 3.1 / Apache 2.0.54 / MySQL 4.0.24 / OTRS 2.0.4





> Hi Andre,

> On Tue, May 23, 2006 at 08:44:21PM +0200, André Bauer wrote:
>><OTRS_CUSTOMER_USEREMAIL> funktioniert bei mir ebenfalls nicht in
>>einer Antwort.

> Hmm, das sollte es aber in einer Standardinstallation.

>>Meinst du mit Mapping das hier?
>>http://doc.otrs.org/2.0/de/html/x1559.html#customer-self-registration-customer-table

> Nein. Öffne mal deine Defaults.pm und such nach " "CustomerUser stuff".
> Darunter beginnt die Konfiguration des verwendeten Customer-Backends:

>     $Self->{CustomerUser} = {
>         Name => 'Database Backend',
>         Module => 'Kernel::System::CustomerUser::DB',
>         ....

> Weiter unten, noch in $Self->{CustomerUser} findest du das Map-Array:

>         Map => [
>             # note: Login, Email and CustomerID needed!
>             # var, frontend, storage, shown (1=always,2=lite),
> required, storage -type, http-link, readonly
>             [ 'UserSalutation', 'Salutation', 'salutation',  1, 0, 'var', '', 0
>             ....

> Wichtig sind hier die Spalten var, frontend, und storage.

> - var stelt die Bezeichnung dar, mit der der Wert in Notifications usw.
>   angesprochen werden kann, also z.B. <OTRS_CUSTOMER_UserSalutation>
> - frontend meint, dass der Wert in der Weboberfläche so bezeichnet wird,
>   also z.B. im Kindeninterface.
> - storage ist der Name der Tabellenspalte in der DB.

>>Irgendwie seh ich da nicht die Verbindung zu meinem Problem? Ist das
>>nicht nur dazu da, dass man fehlende Felder in der Customer.pl
>>hinzufügen kann? 

> Klar, dasMapping lässt sich auch noch erweitern.

>>Daran habe ich auch noch nie Änderungen vorgenommen,
>>da wir unseren Kunden garnicht die Möglichkeit geben, sich am OTRS
>>einzuloggen.

> Aber Kundenbenutzer habt ihr schon, oder?

>>Und wieso muss ich erst am Mapping was ändern, wenn die Variable
>><OTRS_CUSTOMER_USEREMAIL> doch explizit als Beispiel im "Response
>>Management" angegeben ist?

> In meinem Mapping steht (ist ebenfalls eine STandardinstallation):

>             [ 'UserEmail',      'Email',      'email',       0, 1, 'var', '', 0 ],

> Für frontend gibts also den Wert UserEmail, also kann ich die 
> Mailadreese über <OTRS_CUSTOMER_UserEmail> ansprechen.

>>Ich habe gerade noch festgestellt, dass ich die Mailadresse wohl auch
>>über <OTRS_TICKET_CustomerID> und <OTRS_TICKET_CustomerUserID>
>>bekommen kann. Trotzdem verstehe ich nicht warum
>><OTRS_CUSTOMER_USEREMAIL> und <OTRS_CUSTOMER_FROM> nicht
>>funktionieren? Habe ich irgendwo einen Denkfehler und das muss
>>gar nicht ohne Anpassung funktionieren?

> Es sollte mit einer STandardinstallation funzen. Die CustomerID zu 
> verwenden ist übrigens eine schlechte Idee, die muss nicht immer eine 
> Mailadresse sein...

>>André Bauer

> [ !!! TOFU umweltfreundlich entsorgt !!! ]

> Ciao,
> Christian