Dynamische Felder

[KHO]

Hallo Gemeinde,

gibt es eine Anleitung wie ich dynamische Felder in ein Ticketformular einbinden kann?

Gibt es irgendwo eine Darstellung wie das im Ergebnis aussieht?

Egal welche Anleitung oder welchen Forenbeitrag ich verfolge und nachbaue, diese Felder erscheinen einfach nicht. Ich hab 3 dynamische Flder erzeugt, kann aber keine abhängigen dynamischen Felder anlegen. Es gibt allerdings auch keine Fehlermeldung dazu, warum es nicht gehen sollte.

AbhDynFel.JPG

Hintergrund der Geschichte ist das ich bestimmte Felder abhängig vom gewählten Tickettyp einblenden bzw ausblenden möchte.

[jojo]

zeig mal Deine ACL, um welches Frontend/Maske handelt es sich?

[KHO]

Hallo JoJo,

sag mir bitte was ACL ist

Sorry, bin noch nicht so bewandert in dem Thema OTRS. Also meine Ticketmaske sieht so aus:

Maske1.JPG

Ich hoffe das war das was Du meintest oder zumindest ein Teil davon

[jojo]

in welcher Ticketmaske sollen denn abhängige dynamische Felder verwirklicht werden?

Wie willst Du die Abhängigkeit derzeit erreichen?


ACLs: http://doc.otrs.org/3.1/en/html/acl.html

[KHO]

Also die abhängigen Felder sollen idealerweise bei Erstellung eines Quicktickets erscheinen, bzw nicht erscheinen.

Also ich möchte wenn ich wie hier auf Bestellung klicke:

QT.jpg

Das dann zusätzliche Felder zu dem Standardmäßigen Ticketformular eingeblendet werden. Wie zum Beispiel Abteilung, Kostenstelle usw.

Die normale Ticketerstellung kann davon völlig unberührt bleiben.

ACL´s hab ich bis dato noch gar nicht definiert, laut Deinem Link sollten ja Beispiele dafür in der "config.pm" sein, dort ist bei mir aber nix zu finden. Meine "/opt/otrs/Kernel/config.pm" sieht derzeit so aus:

Code: Select all

# --
# Kernel/Config.pm - Config file for OTRS kernel
# Copyright (C) 2001-2008 xxx, http://otrs.org/
# --
# $Id: Config.pm.dist,v 1.20 2008/03/07 16:50:44 martin Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (GPL). If you
# did not receive this file, see http://www.gnu.org/licenses/gpl-2.0.txt.
# --
#  Note:
#
#  -->> OTRS does have a lot of config settings. For more settings
#       (Notifications, Ticket::ViewAccelerator, Ticket::NumberGenerator,
#       LDAP, PostMaster, Session, Preferences, ...) see
#       Kernel/Config/Defaults.pm and copy your wanted lines into "this"
#       config file. This file will not be changed on update!
#
# --

package Kernel::Config;

sub Load {
    my $Self = shift;
    # ---------------------------------------------------- #
    # ---------------------------------------------------- #
    #                                                      #
    #         Start of your own config options!!!          #
    #                                                      #
    # ---------------------------------------------------- #
    # ---------------------------------------------------- #

    # ---------------------------------------------------- #
    # database settings                                    #
    # ---------------------------------------------------- #
    # DatabaseHost
    # (The database host.)
    $Self->{'DatabaseHost'} = 'localhost';
    # Database
    # (The database name.)
    $Self->{'Database'} = 'otrs';
    # DatabaseUser
    # (The database user.)
    $Self->{'DatabaseUser'} = 'otrs';
    # DatabasePw
    # (The password of database user. You also can use bin/CryptPassword.pl
    # for crypted passwords.)
    $Self->{'DatabasePw'} = 'srto';
    # DatabaseDSN
    # (The database DSN for MySQL ==> more: "man DBD::mysql")
    $Self->{DatabaseDSN} = "DBI:mysql:database=$Self->{Database};host=$Self->{DatabaseHost};";

    # (The database DSN for PostgreSQL ==> more: "man DBD::Pg")
    # if you want to use a local socket connection
#    $Self->{DatabaseDSN} = "DBI:Pg:dbname=$Self->{Database};";
    # if you want to use a tcpip connection
#    $Self->{DatabaseDSN} = "DBI:Pg:dbname=$Self->{Database};host=$Self->{DatabaseHost};";

    # ---------------------------------------------------- #
    # fs root directory
    # ---------------------------------------------------- #
    $Self->{Home} = '/opt/otrs';

    # ---------------------------------------------------- #
    # insert your own config settings "here"               #
    # config settings taken from Kernel/Config/Defaults.pm #
    # ---------------------------------------------------- #
    # $Self->{SessionUseCookie} = 0;
    # $Self->{CheckMXRecord} = 0;

    # ---------------------------------------------------- #

    # ---------------------------------------------------- #
    # data inserted by installer                           #
    # ---------------------------------------------------- #
    # $DIBI$
    $Self->{'SystemID'} = 10;
    $Self->{'SecureMode'} = 1;
    $Self->{'Organization'} = 'XXX';
    $Self->{'LogModule::LogFile'} = '/tmp/otrs.log';
    $Self->{'LogModule'} = 'Kernel::System::Log::File';
    $Self->{'FQDN'} = 'XXX';
    $Self->{'DefaultLanguage'} = 'de';
    $Self->{'AdminEmail'} = 'a@b.de';
    $Self->{'DefaultCharset'} = 'utf-8';
    # $Self->{'DefaultCharset'} = 'iso-8859-2';
    # ---------------------------------------------------- #
#########################################################################

#Enable LDdddAP authentication for Customers / Users
  $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
  $Self->{'Customer::AuthModule::LDAP::Host'} = 'XXX';
  $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'XXX';
  $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';

#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'} = 'otrs_ldap';
  $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'XXX';

#CustomerUser
#(customer user database backend and settings)
    $Self->{CustomerUser} = {
      Name => 'LDAP STKM-1',
      Module => 'Kernel::System::CustomerUser::LDAP',
      Params => {
      Host => 'XXX',
      BaseDN => 'XXX',
      SSCOPE => 'sub',
      UserDN =>'otrs_ldap',
      UserPw => 'XXX',
      AlwaysFilter => '(objectclass=user)',
    },
# customer unique id
    CustomerKey => 'sAMAccountName',
    # customer #
    CustomerID => 'mail',
    CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
    CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
    CustomerUserSearchPrefix => '',
    CustomerUserSearchSuffix => '*',
    CustomerUserSearchListLimit => 250,
    CustomerUserPostMasterSearchFields => ['mail'],
    CustomerUserNameFields => ['givenname', 'sn'],
    Map => [
      # note: Login, Email and CustomerID needed!
      # var, frontend, storage, shown, required, storage-type
      #[ 'UserSalutation', 'Title', 'title', 1, 0, 'var' ],
      [ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
      [ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
      [ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
      [ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
      [ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
      [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],
      #[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var' ],
      #[ 'UserComment', 'Comment', 'description', 1, 0, 'var' ],
    ],
  };
########################################################################
    # ---------------------------------------------------- #
    #                                                      #
    #           End of your own config options!!!          #
    #                                                      #
    # ---------------------------------------------------- #
    # ---------------------------------------------------- #
}

# ---------------------------------------------------- #
# needed system stuff (don't edit this)                #
# ---------------------------------------------------- #
use strict;
use warnings;

use vars qw(@ISA $VERSION);
use Kernel::Config::Defaults;
push (@ISA, 'Kernel::Config::Defaults');

use vars qw(@ISA $VERSION);
$VERSION = qw($Revision: 1.20 $)[1];

# -----------------------------------------------------#





#----------- KIX tsunami framework -----------
# CustomPackageLibs ~#
use lib "/opt/otrs/KIXCore";
use lib "/opt/otrs/KIX4OTRS";
use lib "/opt/otrs/KIX4OTRSITSMCore";
use lib "/opt/otrs/KIX4OTRSITSMConfigManagement";
use lib "/opt/otrs/KIX4OTRSITSMIncidentProblem";
use lib "/opt/otrs/KIX4OTRSITSMChangeManagement";

# EO CustomPackageLibs ~#

#----------- EO KIX tsunami framework -----------

1;

[jojo]

Hallo,

die ACLs müssen in die Config.pm eingetragen werden. Beispiele findest Du unter dem bereits geposteten Link unter dem Link "Examples" im grauen Kasten.

Da die Quicktickets keine OTRS Core Funktionalität sind, bin ich allerdings überfragt ob es dort weitere Möglichkeiten gibt.

[KHO]

Ok, was erreiche ich mit diesen ACL´s?

Es muss auch nicht unbedingt an den Quicktickets hängen, primär ist mir wichtig das sich zusätzliche Felder einblenden wenn ich einen bestimmten TicketTyp auswähle, das kann auch gern bei der Erstellung eines normalen "OTRSCore Tickets" passieren.

QT.jpg

Also das ich andere Felder sehe bei Auswahl von "Beschaffung" als bei Auswahl von "Problem".

Eventuell hab ich ja auch einen Denkfehler, aber mus es nicht zu jedem TicketTyp ein Template geben? Oder wird das alles aus dem selbem Template generiert?

[jojo]

In OTRS gibt es Standardmäßig erstmal nur Tickets.

Es gibt ein Feature Add "Ticket Mask Extensions", das kann genau das was Du willst, Felder dynamisch ein und ausblenden in Abhängigkeit vom Typ. Dieses Add On ist aber nur für Supportkunden zugänglich.

Ggf. auch interessant könnten die Ticket Processe sein, diese sind ab der Version 3.2. verfügbar (schau mal in das 3.2er Handbuch).

Ich rate Dir allerdings zu einem Workshop mit einem OTRS erfahrenem Consultant um entsprechende Möglichkeiten auszuloten

[KHO]

Dieses Add On ist mir bekannt, aber schade das es nur Support Kunden zugänglich ist, ich sehe nicht ganz den Sinn darin für minimum 4000 Euro im Jahr Support zu kaufen um 1 Modul nutzen zu können, ein einmaliger Anschaffungspreis wäre ja noch gerechtfertigt.

Aber wozu sind die dynamischen Felder dann da? In welchen Szenarien machen die dann Sinn?

Ticket Prozesse? Das guck ich mir mal an, die 3.2 ist allerdings noch ne Beta oder?

Den Workshop werd ich auf jeden Fall in Anspruch nehmen, das kann sicherlich nicht schaden.

[jojo]

Dynamsiche Felder dienen dazu zusätzliche Informationen zu Tickets aufzunehmen