Eine Aufzeichnung darüber, mit wem sich Ihr Unternehmen befasst, erfordert weitere Informationen über diese Person: Den physischen Standort für Versand- und Rechnungszwecke sowie Kontaktinformationen für E-Mail- und Telefonkontakt.
OTRS bietet eine großartige Möglichkeit, individuelle Informationen über Kontakte innerhalb von Unternehmen zu speichern. Sie können beliebig viele persönliche Verbindungen zu OTRS hinzufügen.
Verwenden Sie diese Ansicht, um einen customer user zum System hinzuzufügen. Eine OTRS-Neuinstallation enthält standardmäßig keine Kundenbenutzer. Die Ansicht zur Verwaltung der Kundenbenutzer ist im Modul Kundenbenutzer in der Gruppe Benutzer, Gruppen und Rollen verfügbar.

Kundenbenutzer verwalten
Warnung
Ein Kundenbenutzer kann dem System nur hinzugefügt werden, wenn wenigstens ein Kunde existiert. Erstellen Sie zuerst einen oder mehrere Kunden.
Bemerkung
Das Hinzufügen oder Bearbeiten eines Kundenbenutzers ist nur über das Datenbank-Backend möglich. Die Verwendung externer Verzeichnisdienste wie LDAP deaktiviert die Benutzerverwaltung des Kunden.
So fügen Sie einen Kundenbenutzer hinzu:
-
Klicken Sie in der linken Seitenleiste auf die Schaltfläche Kundenbenutzer hinzufügen.
-
Füllen Sie die Pflichtfelder aus.
-
Klicken Sie auf die Schaltfläche Speichern.

Warnung
Kundenbenutzer können nicht aus dem System gelöscht werden. Sie können nur deaktiviert werden, wenn die Einstellung Gültigkeit auf ungültig oder ungültig-temporär gesetzt wird.
So bearbeiten Sie einen Kundenbenutzer:
-
Klicken Sie in der Liste mit den Kundenbenutzern auf einen Kundenbenutzer.
-
Ändern Sie die Felder.
-
Klicken Sie auf die Schaltfläche Speichern oder Speichern und abschließen.

So finden Sie einen Kundenbenutzer:
-
Geben Sie einen Suchbegriff in das Suchfeld in der linken Seitenleiste ein.
-
Klicken Sie auf das Lupen-Symbol oder betätigen Sie
Eingabe
.
Bemerkung
Wenn dem System mehrere Kundenbenutzer hinzugefügt wurden, nutzen Sie das Suchfeld, um einen einzelnen Kunden zu finden. Standardmäßig werden nur die ersten 1000 Kundenbenutzer angezeigt.
Die Berechtigungen des Agenten können gesteuert werden, indem ein Kunde oder Kundenbenutzer zu Gruppen hinzugefügt wird. Dies kann zu einer komplexen Matrix von Berechtigungen führen. Die effektiven Berechtigungen für einen Kundenbenutzer können unten auf der Ansicht Kundenbenutzer bearbeiten überprüft werden.

Siehe auch
Kundenbenutzer ↔ Gruppen muss aktiviert sein, um diese Funktion zu nutzen.
Einstellungen für Kundenbenutzer
Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.
Bemerkung
Dies sind die Standardfelder, die für die interne Datenbank-Tabelle zur Verfügung stehen.
- Titel oder Anrede
-
Hier können einige Präfixe, wie bspw. Dr. oder Prof. etc. hinzugefügt werden.
- Vorname *
-
Der Vorname des Kundenbenutzers.
- Nachname *
-
Der Nachname des Kundenbenutzers.
- Benutzername *
-
Der Benutzername des Kundenbenutzers zur Anmeldung am System.
- Passwort
-
Das Passwort des Kundenbenutzers. Wird automatisch generiert, wenn das Feld leer gelassen wird.
- E-Mail *
-
Die E-Mail-Adresse des Kundenbenutzers.
- Kunde *
-
Das Unternehmen zu dem der Kundenbenutzer gehört. Wählen Sie einen Kunden aus der Liste der Kunden.
- Telefon
-
Die Telefonnummer des Kundenbenutzers.
- Fax
-
Die Faxnummer des Kundenbenutzers.
- Mobiltelefon
-
Die Handynummer des Kundenbenutzers.
- Straße
-
Der Straßenname der Adresse des Kunden.
- PLZ
-
Die PLZ der Adresse des Kunden.
- Stadt
-
Die Stadt der Adresse des Kunden.
- Land
-
Das Land des Kundenbenutzers.
- Kommentar
-
Fügen Sie dieser Ressource zusätzliche Informationen hinzu. Es wird empfohlen, dieses Feld als Beschreibung der Ressource zur besseren Übersichtlichkeit immer mit einem vollständigen Satz zu füllen, da der Kommentar auch in der Übersichtstabelle angezeigt wird.
- Gültigkeit *
-
Setzt die Gültigkeit dieser Ressource. Jede Ressource kann nur in OTRS verwendet werden, wenn dieses Feld auf gültig gesetzt ist. Wenn Sie dieses Feld auf ungültig oder ungültig-temporär setzen, wird die Nutzung der Ressource deaktiviert.
Siehe auch
Es ist möglich, mehrere Kunden den Kundenbenutzern über die Ansicht Kundenbenutzer ↔ Kunden zuzuordnen.
Kundenbenutzer-Backends
Das System arbeitet mit vielen Kundendatenattributen wie Benutzername, E-Mail-Adresse, Telefonnummer, etc. zusammen. Diese Attribute werden sowohl im Agenten als auch im externen Interface angezeigt und auch für die Authentifizierung von Kundenbenutzern verwendet.
Die im System verwendeten oder angezeigten Kundendaten sind sehr anpassungsfähig. Die Benutzeranmeldung und die E-Mail-Adresse werden immer für die Kundenauthentifizierung benötigt.
Das Administrator-Interface unterstützt nicht die Konfiguration von externen Backends. Administratoren müssen die Datei Kernel/Config.pm
bearbeiten, indem Sie Codeausschnitte aus Kernel/Config/Defaults.pm
manuell kopieren und einfügen, wenn sie On-Premise-System verwenden.
Wenn Sie bereits ein anderes Kunden-Backend (z. B. SAP) haben, können Sie ein Modul schreiben, das dieses verwendet.
Warnung
Ändern Sie die Datei Kernel/Config/Defaults.pm
nicht, sie wird nach dem Upgrade des Systems überschrieben! Kopieren und fügen Sie die Codeschnipsel stattdessen in Kernel/Config.pm
ein.
Bemerkung
Diese Funktion ist nur für On-Premise-Kunden verfügbar. Wenn Sie ein Managed-Kunde sind, wird diese Funktion vom Customer Solutions Team in OTRS betreut. Bitte kontaktieren Sie uns über support@otrs.com oder im OTRS Portal.
Kundenbenutzer Back End – Datenbank
Das Standard-Benutzerauthentifizierungs-Backend für Kundenbenutzer ist die OTRS-Datenbank. Mit diesem Backend können alle Kundenbenutzerdaten über das Administrator-Interface bearbeitet werden.
# This is the auth. module for the otrs db
# you can also configure it using a remote database
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::DB';
$Self->{'Customer::AuthModule::DB::Table'} = 'customer_user';
$Self->{'Customer::AuthModule::DB::CustomerKey'} = 'login';
$Self->{'Customer::AuthModule::DB::CustomerPassword'} = 'pw';
# $Self->{'Customer::AuthModule::DB::DSN'} = "DBI:mysql:database=customerdb;host=customerdbhost";
# $Self->{'Customer::AuthModule::DB::User'} = "some_user";
# $Self->{'Customer::AuthModule::DB::Password'} = "some_password";
# if you use odbc or you want to define a database type (without autodetection)
# $Self->{'Customer::AuthModule::DB::Type'} = 'mysql';
# password crypt type (bcrypt|sha2|sha1|md5|apr1|crypt|plain)
# $Self->{'Customer::AuthModule::DB::CryptType'} = 'sha2';
Das folgende Beispiel zeigt die Konfiguration eines Datenbank-Kunden-Backends, das die in der Datenbanktabelle customer_user
gespeicherten Kundenbenutzerdaten verwendet.
# CustomerUser
# (customer user database backend and settings)
$Self->{CustomerUser} = {
Name => Translatable('Database Backend'),
Module => 'Kernel::System::CustomerUser::DB',
Params => {
# if you want to use an external database, add the
# required settings
# DSN => 'DBI:odbc:yourdsn',
# Type => 'mssql', # only for ODBC connections
# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',
# User => '',
# Password => '',
Table => 'customer_user',
# ForeignDB => 0, # set this to 1 if your table does not have create_time, create_by, change_time and change_by fields
# CaseSensitive defines if the data storage of your DBMS is case sensitive and will be
# preconfigured within the database driver by default.
# If the collation of your data storage differs from the default settings,
# you can set the current behavior ( either 1 = CaseSensitive or 0 = CaseINSensitive )
# to fit your environment.
#
# CaseSensitive => 0,
# SearchCaseSensitive will control if the searches within the data storage are performed
# case sensitively (if possible) or not. Change this option to 1, if you want to search case sensitive.
# This can improve the performance dramatically on large databases.
SearchCaseSensitive => 0,
},
# customer unique id
CustomerKey => 'login',
# customer #
CustomerID => 'customer_id',
CustomerValid => 'valid_id',
# The last field must always be the email address so that a valid
# email address like "John Doe" <john.doe@domain.com> can be constructed from the fields.
CustomerUserListFields => [ 'first_name', 'last_name', 'email' ],
# CustomerUserListFields => ['login', 'first_name', 'last_name', 'customer_id', 'email'],
CustomerUserSearchFields => [ 'login', 'first_name', 'last_name', 'customer_id' ],
CustomerUserSearchPrefix => '*',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['email'],
CustomerUserNameFields => [ 'title', 'first_name', 'last_name' ],
CustomerUserEmailUniqCheck => 1,
# # Configures the character for joining customer user name parts. Join single space if it is not defined.
# # CustomerUserNameFieldsJoin => '',
# # show now own tickets in customer panel, CompanyTickets
# CustomerUserExcludePrimaryCustomerID => 0,
# # generate auto logins
# AutoLoginCreation => 0,
# # generate auto login prefix
# AutoLoginCreationPrefix => 'auto',
# # admin can change customer preferences
# AdminSetPreferences => 1,
# use customer company support (reference to company, See CustomerCompany settings)
CustomerCompanySupport => 1,
# cache time to live in sec. - cache any database queries
CacheTTL => 60 * 60 * 24,
# # Consider this source read only.
# ReadOnly => 1,
Map => [
# Info about dynamic fields:
#
# Dynamic Fields of type CustomerUser can be used within the mapping (see example below).
# The given storage (third column) then can also be used within the following configurations (see above):
# CustomerUserSearchFields, CustomerUserPostMasterSearchFields, CustomerUserListFields, CustomerUserNameFields
#
# Note that the columns 'frontend' and 'readonly' will be ignored for dynamic fields.
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[ 'UserTitle', Translatable('Title or salutation'), 'title', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserFirstname', Translatable('Firstname'), 'first_name', 1, 1, 'var', '', 0, undef, undef ],
[ 'UserLastname', Translatable('Lastname'), 'last_name', 1, 1, 'var', '', 0, undef, undef ],
[ 'UserLogin', Translatable('Username'), 'login', 1, 1, 'var', '', 0, undef, undef ],
[ 'UserPassword', Translatable('Password'), 'pw', 0, 0, 'var', '', 0, undef, undef ],
[ 'UserEmail', Translatable('Email'), 'email', 1, 1, 'var', '', 0, undef, undef ],
# [ 'UserEmail', Translatable('Email'), 'email', 1, 1, 'var', '[% Env("CGIHandle") %]?Action=AgentTicketCompose;ResponseID=1;TicketID=[% Data.TicketID | uri %];ArticleID=[% Data.ArticleID | uri %]', 0, '', 'AsPopup OTRSPopup_TicketAction' ],
[ 'UserCustomerID', Translatable('CustomerID'), 'customer_id', 0, 1, 'var', '', 0, undef, undef ],
# [ 'UserCustomerIDs', Translatable('CustomerIDs'), 'customer_ids', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserPhone', Translatable('Phone'), 'phone', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserFax', Translatable('Fax'), 'fax', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserMobile', Translatable('Mobile'), 'mobile', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserStreet', Translatable('Street'), 'street', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserZip', Translatable('Zip'), 'zip', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserCity', Translatable('City'), 'city', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserCountry', Translatable('Country'), 'country', 1, 0, 'var', '', 0, undef, undef ],
[ 'UserComment', Translatable('Comment'), 'comments', 1, 0, 'var', '', 0, undef, undef ],
[ 'ValidID', Translatable('Valid'), 'valid_id', 0, 1, 'int', '', 0, undef, undef ],
# Dynamic field example
# [ 'DynamicField_Name_X', undef, 'Name_X', 0, 0, 'dynamic_field', undef, 0, undef, undef ],
],
# default selections
Selections => {
# UserTitle => {
# 'Mr.' => Translatable('Mr.'),
# 'Mrs.' => Translatable('Mrs.'),
# },
},
};
Wenn Sie die Kundenbenutzerdaten anpassen möchten, ändern Sie die Spalten oder fügen Sie neue Spalten zur Tabelle „customer_user“ in der Datenbank hinzu.
Zum Beispiel, um ein neues Feld für die Raumnummer hinzuzufügen:
-
Fügen Sie eine neue Spalte
Raum
zur Tabellecustomer_user
hinzu.MySQL oder MariaDB:
root> mysql -u root -p -e 'ALTER TABLE otrs.customer_user ADD room VARCHAR (250)'
PostgreSQL (aus dem Verzeichnis
/opt/otrs
):otrs> psql -c 'ALTER TABLE customer_user ADD COLUMN room varchar(250)'
-
Kopieren Sie den Abschnitt
$Self->{CustomerUser}` von ``Kernel/Config/Defaults.pm
nachKernel/Config.pm
. -
Fügt die neue Spalte zum Array
Map
hinzu.[ 'UserRoom', 'Room', 'room', 0, 1, 'var', '', 0, undef, undef ],
Sie können das HTTP-Link-Ziel und die Link-Klasse (die letzten beiden Schlüssel) in Map-Array-Elementen auf
undef
einstellen, wenn sie nicht verwendet werden sollen. Diese Schlüssel fügen dem HTTP-Link-Element jeweilstarget=""
undclass=""
Attribute hinzu. Sie werden ignoriert, wenn die HTTP-Verbindung nicht gesetzt ist (in diesem Beispiel ist es''
). -
Fügen Sie das neue Feld in den Ansicht zum Anlegen und Aktualisieren von Kundenbenutzern ein.
Relevante Systemkonfigurationen:
-
Forms###AgentFrontend::CustomerUserCreate::Properties
-
Forms###AgentFrontend::CustomerUserUpdate::Properties
-
Bemerkung
Es wird empfohlen, für Namen immer englische Wörter zu verwenden.
Siehe auch
Namen können mit benutzerdefinierten Sprachdateien in andere Sprachen übersetzt werden. Weitere Informationen finden Sie im Kapitel Benutzerdefinierte Sprachdatei.
Kundenbenutzer-Backend – LDAP
Wenn Sie über ein LDAP-Verzeichnis mit allen Benutzerdaten Ihrer Kunden verfügen, können Sie das LDAP-Modul zur Authentifizierung Ihrer Kundenbenutzer verwenden. Da dieses Modul nur Lesezugriff auf das LDAP-Backend hat, ist es nicht möglich, die Kundenbenutzerdaten über das Administrator-Interface zu bearbeiten.
# This is an example configuration for an LDAP auth. backend.
# (take care that Net::LDAP is installed!)
# $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
# $Self->{'Customer::AuthModule::LDAP::Host'} = 'ldap.example.com';
# $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com';
# $Self->{'Customer::AuthModule::LDAP::UID'} = 'uid';
# Check if the user is allowed to auth in a posixGroup
# (e. g. user needs to be in a group xyz to use otrs)
# $Self->{'Customer::AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com';
# $Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid';
# for ldap posixGroups objectclass (just uid)
# $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';
# for non ldap posixGroups objectclass (full user dn)
# $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
# The following is valid but would only be necessary if the
# anonymous user do NOT have permission to read from the LDAP tree
# $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = '';
# $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = '';
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
# $Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = '';
# in case you want to add a suffix to each customer login name, then
# you can use this option. e. g. user just want to use user but
# in your ldap directory exists user@domain.
# $Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '@domain.com';
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
# $Self->{'Customer::AuthModule::LDAP::Params'} = {
# port => 389,
# timeout => 120,
# async => 0,
# version => 3,
# };
# Die if backend can't work, e. g. can't connect to server.
# $Self->{'Customer::AuthModule::LDAP::Die'} = 1;
Das folgende Beispiel zeigt die Konfiguration eines LDAP-Kundenbenutzer-Backends.
# CustomerUser
# (customer user ldap backend and settings)
$Self->{CustomerUser} = {
Name => 'LDAP Backend',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
# ldap host
Host => 'bay.csuhayward.edu',
# ldap base dn
BaseDN => 'ou=seas,o=csuh',
# search scope (one|sub)
SSCOPE => 'sub',
# The following is valid but would only be necessary if the
# anonymous user does NOT have permission to read from the LDAP tree
UserDN => '',
UserPw => '',
# in case you want to add always one filter to each ldap query, use
# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
AlwaysFilter => '',
# if the charset of your ldap server is iso-8859-1, use this:
# # SourceCharset => 'iso-8859-1',
# die if backend can't work, e. g. can't connect to server
Die => 0,
# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
# customer unique id
CustomerKey => 'uid',
# customer #
CustomerID => 'mail',
CustomerUserListFields => ['cn', 'mail'],
CustomerUserSearchFields => ['uid', 'cn', 'mail'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
# Configures the character for joining customer user name parts. Join single space if it is not defined.
CustomerUserNameFieldsJoin => '',
# show customer user and customer tickets in the external interface
CustomerUserExcludePrimaryCustomerID => 0,
# add a ldap filter for valid users (expert setting)
# # CustomerUserValidFilter => '(!(description=gesperrt))',
# admin can't change customer preferences
AdminSetPreferences => 0,
# cache time to live in sec. - cache any ldap queries
# CacheTTL => 0,
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
[ 'UserTitle', Translatable('Title or salutation'), 'title', 1, 0, 'var', '', 1, undef, undef ],
[ 'UserFirstname', Translatable('Firstname'), 'givenname', 1, 1, 'var', '', 1, undef, undef ],
[ 'UserLastname', Translatable('Lastname'), 'sn', 1, 1, 'var', '', 1, undef, undef ],
[ 'UserLogin', Translatable('Username'), 'uid', 1, 1, 'var', '', 1, undef, undef ],
[ 'UserEmail', Translatable('Email'), 'mail', 1, 1, 'var', '', 1, undef, undef ],
[ 'UserCustomerID', Translatable('CustomerID'), 'mail', 0, 1, 'var', '', 1, undef, undef ],
# [ 'UserCustomerIDs', Translatable('CustomerIDs'), 'second_customer_ids', 1, 0, 'var', '', 1, undef, undef ],
[ 'UserPhone', Translatable('Phone'), 'telephonenumber', 1, 0, 'var', '', 1, undef, undef ],
[ 'UserAddress', Translatable('Address'), 'postaladdress', 1, 0, 'var', '', 1, undef, undef ],
[ 'UserComment', Translatable('Comment'), 'description', 1, 0, 'var', '', 1, undef, undef ],
# this is needed, if "SMIME::FetchFromCustomer" is active
# [ 'UserSMIMECertificate', 'SMIMECertificate', 'userSMIMECertificate', 0, 1, 'var', '', 1, undef, undef ],
# Dynamic field example
# [ 'DynamicField_Name_X', undef, 'Name_X', 0, 0, 'dynamic_field', undef, 0, undef, undef ],
],
};
So aktivieren und konfigurieren Sie das LDAP-Backend:
-
Kopieren Sie den Abschnitt
$Self->{CustomerUser}` von ``Kernel/Config/Defaults.pm
nachKernel/Config.pm
. -
Entfernen Sie die Kommentare (
#
Zeichen) am Anfang der Zeilen.
Sind in Ihrem LDAP-Verzeichnis weitere Kundenbenutzer-Attribute hinterlegt, wie z.B. ein Vorgesetzter, eine Mobiltelefonnummer oder eine Abteilung, können diese Informationen in OTRS angezeigt werden.
So zeigen Sie zusätzliche Kundenbenutzer-Attribute aus dem LDAP-Verzeichnis an:
-
Erweitern Sie das Array
Map
inKernel/Config.pm
mit den Einträgen für diese Attribute.[ 'UserMobilePhone', 'Mobile Phone', 'mobilephone', 1, 0, 'var', '', 1, undef, undef ],
Bemerkung
Es wird empfohlen, für Namen immer englische Wörter zu verwenden.
Siehe auch
Namen können mit benutzerdefinierten Sprachdateien in andere Sprachen übersetzt werden. Weitere Informationen finden Sie im Kapitel Benutzerdefinierte Sprachdatei.
Kundenbenutzer-Backend – HTTPBasicAuth
Wenn Sie eine Single-Sign-On-Lösung für alle Ihre Kunden implementieren möchten, können Sie HTTPBasic-Authentifizierung (für alle Ihre Systeme) verwenden und das HTTPBasicAuth-Modul mit OTRS nutzen. Mit OTRS ist keine Anmeldung mehr erforderlich.
# This is an example configuration for an apache ($ENV{REMOTE_USER})
# auth. backend. Use it if you want to have a singe login through
# apache http-basic-auth
# $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
# In case there is a leading domain in the REMOTE_USER, you can
# replace it by the next config option.
# $Self->{'Customer::AuthModule::HTTPBasicAuth::Replace'} = 'example_domain\\';
# Note:
# In case you need to replace some part of the REMOTE_USER, you can
# use the following RegExp ($1 will be new login).
# $Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'} = '^(.+?)@.+?$';
# Defines a header name, that has to be present for customers to authenticate.
# $Self->{'Customer::AuthModule::HTTPBasicAuth::RequiredLoginHeader'} = 'RequiredHeader';
# Defines a header value, that has to be present in the required header for customers to authenticate.
# $Self->{'Customer::AuthModule::HTTPBasicAuth::RequiredLoginHeaderValue'} = 'RequiredHeaderValue';
# Defines a header value regular expression, that has to be present in the required header for customers to authenticate.
# $Self->{'Customer::AuthModule::HTTPBasicAuth::RequiredLoginHeaderValueRegExp'} = '^RequiredHeaderRegExp$';
# If you use this module, you should use as fallback the following
# config settings if user isn't login through apache ($ENV{REMOTE_USER})
# $Self->{CustomerPanelLoginURL} = 'http://host.example.com/not-authorised-for-otrs.html';
# $Self->{CustomerPanelLogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html';
Kundenbenutzer Back End – Radius
Die im folgenden Beispiel gezeigten Einstellungen können verwendet werden, um Ihre Kundenbenutzer gegenüber einem Radius-Server zu authentifizieren.
# This is example configuration to auth. agents against a radius server
# $Self->{'Customer::AuthModule'} = 'Kernel::System::Auth::Radius';
# $Self->{'Customer::AuthModule::Radius::Host'} = 'radiushost';
# $Self->{'Customer::AuthModule::Radius::Password'} = 'radiussecret';
Backends für mehrere Kundenbenutzer
Wenn Sie mehr als eine Kundenbenutzer-Datenquelle verwenden möchten, sollte der Konfigurationsparameter CustomerUser
um eine Zahl erweitert werden, wie CustomerUser1` und CustomerUser2
.
Das folgende Konfigurationsbeispiel zeigt die Verwendung sowohl einer Datenbank als auch eines LDAP-Kundenbenutzer-Backends.
# Data source 1: customer user database back end and settings.
$Self->{CustomerUser1} = {
Name => 'Database Backend',
Module => 'Kernel::System::CustomerUser::DB',
Params => {
DSN => 'DBI:odbc:yourdsn',
DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',
User => '',
Password => '',
Table => 'customer_user',
},
# Other setting here.
};
# Data source 2: customer user LDAP back end and settings.
$Self->{CustomerUser2} = {
Name => 'LDAP Backend',
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => 'bay.csuhayward.edu',
BaseDN => 'ou=seas,o=csuh',
SSCOPE => 'sub',
UserDN => '',
UserPw => '',
AlwaysFilter => '',
Die => 0,
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
# Other setting here.
};
Es ist möglich, bis zu 10 verschiedene Kunden-Backends zu integrieren. Verwenden Sie die Ansicht Kundenbenutzer, um alle Kundenbenutzerdaten anzuzeigen oder zu bearbeiten (vorausgesetzt, der Schreibzugriff ist aktiviert).
Kundenbenutzer-Daten in dynamischen Feldern
Manchmal kann es sinnvoll sein, Kundenbenutzer-Daten auch direkt in dynamischen Feldern eines Tickets zu speichern, z.B. um diese Daten später in spezielle Statistiken aufzunehmen.
Die Werte der dynamischen Felder werden festgelegt, wenn ein Ticket erstellt wird oder wenn der Kundenbenutzer eines Tickets geändert wird. Die Werte der dynamischen Felder werden aus den Kundenbenutzer-Daten übernommen. Dies funktioniert für alle Backends, ist aber besonders nützlich für LDAP-Backends.
Aktivieren Sie diese Option um die Werte als Baum anzuzeigen:
-
Aktivieren Sie die Einstellung
Ticket::EventModulePost###4100-DynamicFieldFromCustomerUser
. -
Aktivieren Sie die Einstellung
DynamicFieldFromCustomerUser::Mapping
, und ändern Sie den Wert. Diese Einstellung sollte die Zuordnung zwischen den Feldnamen von Kundenbenutzern und den Namen dynamischer Felder enthalten, die deren Werte erben werden. -
Erstellen Sie die dynamischen Felder, wenn die dynamischen Felder noch nicht im System vorhanden sind.
-
Aktivieren Sie die Anzeige der dynamischen Felder im Eigenschaften-Widget, so dass Sie ihre aktuellen Werte leicht überprüfen können. Sie können dies über folgende Anweisungen following instructions tun.
Bemerkung
Die betreffenden dynamischen Felder dürfen in den folgenden Aktionsformularen nicht aktiviert werden:
-
Forms###AgentFrontend::TicketCreate::Email::CreateProperties
-
Forms###AgentFrontend::TicketCreate::Phone::CreateProperties
-
Forms###AgentFrontend::TicketCreate::SMS::CreateProperties
-
Forms###AgentFrontend::Ticket::Action::Customer
Wenn dies der Fall wäre, hätten die Feldwerte aus der Ansicht Vorrang vor den automatisch eingestellten Werten.