• Deutsch
  • English
  • Anmeldung OTOBO Community
+49 (0)9427 68 39 000
OTOBO
  • SOFTWARE
    • Software | Überblick
    • IT Service Management
    • Customer Service Management
    • Enterprise Service Management
    • Demo
    • Download
    • Dokumentation
  • SERVICES
    • Überblick Services
    • Beratung
    • Training
    • Entwicklung
    • OTRS Migration zu OTOBO
    • Support
    • Managed Service
    • Support-Portal
  • UNTERNEHMEN
    • Über uns
    • Karriere
    • Partner
    • Kontakt
    • Newsletter
  • RESSOURCEN
  • COMMUNITY
    • Open Source
    • Community Forum
    • Download
    • Dokumentation
    • OTOBO übersetzen
  • Click to open the search input field Click to open the search input field Suche
  • Menü Menü

Schlagwörter: TicketDynamicFieldUpdate Ticket-Benachrichtigung Dynamische Felder

Ansicht von 1 Antwort-Thread
  • Autor
    Beiträge
    • 26. Oktober 2022 um 12:14 Uhr - Views: 921 #14140
      Philipp Ghirardini
      Teilnehmer

        Native OTOBO 10.0.15 Installation auf OpenSuse.

        Hallo,

        ich bin mir nicht sicher ob es ein Bug ist oder nur ein Anwendungsfehler.

        Ich habe ein dynamisches Feld (Kontrollbox) und würde gerne an den Kunden eine Nachricht schreiben sobald sich der Wert dieses Feldes ändert. Ich habe dies bereits mit dem Priorität Feld eingerichtet und dort funktioniert es wie gedacht.

        Das dynamische Feld kann nur über das Priorität Formular des Agenten gesetzt werden. Das Problem ist, dass dynamische Felder beim Erzeugen nicht den definierten Default Wert bekommen, sondern auf „“ gesetzt sind.

        Da „“ aber kein gültiger Wert bei dynamischen Feldern ist (habe es auch mit Einwahlauswahlfeld getestet) wird beim Abspeichern des Formulars immer der TicketDynamicFieldUpdate Event ausgelöst, auch wenn der Wert aus Agentensicht eigentlich nicht geändert wurde, sondern nur der Default Wert erstmals gesetzt wurde.

        Ich habe bereits versucht Ticket::EventModulePost###9600-TicketDynamicFieldDefault zu verwenden um den Wert beim Erzeugen des Tickets immer zu setzen. Das funktioniert auch, leider löst es dann aber den Event sofort aus und der Kunde wird fälschlicherweise über das setzten des Default Wertes informiert.

        Eine letzte Möglichkeit wäre noch den Default Wert über den GenericAgent zu setzen mit der Option keine Benachrichtigung zu senden. Davon habe ich aber noch auf Grund des Bugs 1918  abgesehen. Außerdem erscheint es mir als nicht sehr schöner Workaround.

        Hat hiermit jemand Erfahrungen gemacht oder handelt es ich eher um einen Bug? Aus meiner Sicht ist so nämlich das Ereignis TicketDynamicFieldUpdate nicht wirklich anwendbar.

        Danke & lg, Philipp

         

         

      • 26. Oktober 2022 um 16:45 Uhr #14145
        Stefan Abel
        Moderator

          Hallo,

          Kontrollkästchen sind immer so eine Sache.
          Aber vielleicht kann man noch ein zweites Feld zusätzlich benutzen, das nur gesetzt wird, wenn der Wert wirklich gesetzt wird. und dann die Benachrichtigung auf dieses zweite Feld triggern.

          Ansonsten bin ich mir nicht sicher, ob ich den use case verstehe, weil ich mir nicht sicher bin, weshalb man bei einem Kontrollkästchen einen Standardwert benötigt.

          Ggf. ein Dropdown/Einfachauswahlfeld benutzen und darauf triggern.

          Viele Grüße
          Stefan

          • 26. Oktober 2022 um 20:21 Uhr #14150
            Philipp Ghirardini
            Teilnehmer

              Hallo,

              danke für die Antwort. Leider habe ich es auch mit einem Einfachauswahlfeld schon probiert, mit dem selben Ergebnis. Wird ein Ticket angelegt und wird dabei das dynamische Feld nicht angezeigt (z.B.: Ticket per Mail oder per Kundenportal) bekommen scheinbar alle dynamischen Felder (getestet mit Einmalauswahlfeld und Kontrollbox) einen leeren String als Wert.

              Erst wenn man ein Formular abspeichert in welchem das dynamische Feld sichtbar ist wird tatsächlich ein Wert gesetzt. Da dieser Wert immer eine Änderung zum leeren String ist wird auch immer das Ereignis TicketDynamicFieldUpdate ausgelöst. Lässt man den Default Wert, sollte meiner Meinung nach kein Event ausgelöst werden, da es ja aus Benutzersicht keine Änderung ist.

              Technisch gesehen, haben also alle dynamischen Felder einen zusätzlichen Wert, nämlich einen leeren String. Das Kontrollkästchen hat z.B.: 3 mögliche Werte und bei jedem Übergang wird das Event ausgelöst:

              • Leeren String … bei der Ticketerstellung (egal ob als Default ausgewählt/nicht ausgewählt wurde)
              • 0 … wenn ein Formular gespeichert wird und das Kontrollkästchen nicht angehackt ist
              • 1 … wenn ein Formular gespeichert wird und das Kontrollkästchen angehackt ist

              lg, Philipp

        • Autor
          Beiträge
        Ansicht von 1 Antwort-Thread
        • Du musst angemeldet sein, um auf dieses Thema antworten zu können.

        Foren durchsuchen

        Anmeldung

        Anmeldung

        Konto erstellen
        Passwort vergessen?

        Login via Social

        Profil

        Bitte vervollständigen Sie nach der Registrierung Ihr Profil, das vereinfacht die spätere Kommunikation enorm. Ihre Profileinstellung finden Sie, wenn Sie auf Ihr Avatarbild klicken.

        Sie können Ihren Avatar ändern, indem Sie sich mit Ihrer E-Mail-Adresse unter gravatar.com registrieren.

        Letzte Aktivitäten

        • Queues ändern per Script oder Massenänderung
        • Mandantenfähigkeit
        • Dynamische Felder in AgentTicketNote mit ACL verstecken
        • FAQ: kaputtes Copy & Paste von Bildern zwischen Artikeln
        • Benachrichtigung „Ticket wurde mir entzogen“ möglich?

        Unternehmen

        Über uns
        Karriere
        Stellenbörse
        Partner werden
        Kontakt
        Newsletter

        OTOBO | Simplify work and create exceptional service experiences.

        Die Source Code Owner und Maintainer hinter OTOBO.

        Software

        Service Management-Plattform
        OTOBO Demo
        OTOBO Download
        OTOBO Dokumentation

        Security-Problem melden:
        security@otobo.org

        Services

        Support-Portal
        Beratung
        Training
        Support
        Managed Services
        Erweiterung
        OTRS Migration
        Partner finden

        Community

        Open Source
        Community Forum
        Mitmachen
        OTOBO Developer
        OTOBO@GitHub

        © 2026 Rother OSS GmbH | All rights reserved.
        • Cookie-Einstellungen
        • Impressum
        • Datenschutz
        • Haftungsausschluss
        Nach oben scrollen Nach oben scrollen Nach oben scrollen