SDM: CaseType über Benutzer bei Mail

Welcome to the POB User Group Online Community! Forums PUG DACH SDM: CaseType über Benutzer bei Mail

Tagged: , ,

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #2964

    Hoi Pugler,

    wir binden verschiedene Mail-Adressen ein und hinterlegen entsprechend unterschiedlich die Bearbeiter/Benutzer(bereits auf dem Server).

    Nun möchten wir abhängig vom Bearbeiter den CaseType setzen.
    Dafür habe ich eine Update-Condition im Case auf das Feld gesetzt(Geändert), sofern der CaseType leer ist.

    Da der Default CaseType in dem Benutzer in einer Unteransicht liegt, ist die PQL Zuweisung etwas schwierig. In etwa so …

    ‘[ct.CaseTypePK|CaseType ct, UserSDMSettings uc, UserTable u, CaseTable c|ct.CaseTypePK=uc.DefaultCaseTypePK AND u.UserPK=uc.UserPK AND uc.UserPK=[UserPK]]’

    Wenn s das Objekt für Sumbitted Answer, welches Kürzel steht dann für den Falltyp?
    (Müsste ct.CaseTypePK dadurch ersetzen) (1)
    Gibt es für die Objektkürzel eine Liste? (2)

    Ist es richtig sich mit den eckigen Klammern auf den aktuellen Datensatz(Case) zu beziehen? (3)

    Gibt es generall für die Aufgabenstellung eine bessere Lösung? (4)

    #2965
    Timm
    Member

    Hi Marc,

    4.) Ich habe unterschiedliche Postfächer (Empfängeradressen), die POB abholt.

    Ich habe auf der Mail-Tabelle entsprechend Triggger liegen, die den Vorgang manipulieren (auch CaseType, etc…)

    Die Trigger/Conditions laufen auf System Master Data -> Modules -> CMD -> Mail

    Lege dir eine Condition an
    Action: Update (Aktualisieren)

    AND Condition:
    MailStatus geändert in Empfangen
    MailFrom = ‘MeineEmail@Email.com’

    In der DataAction dahinter machst du die Manipulation mit
    Action: Update
    Zieltabelle: Case
    Kriterien: CasePK=[RootPK]

    Dann manipulierst du von der Mailtabelle aus deine Cases …

    Das wäre meine Lösung…

    LG
    Timm

    #2966

    Hallo Timm,

    das war mein erster Ansatz, aber ich möchte nicht sechs Trigger aufbauen, wenn es einer auch tun würde. (Es würde bei dem einer neuen Mail-Adresse auch funktionieren ohne POB-Administration)
    Der Triggerwald wird ohnehin immer größer und undurchsichtiger …

    Knackpunkt ist wie so oft das PQL …

    #2967
    Timm
    Member

    Hallo Marc,

    okay ich habe nur 3 Postfächer, somit ist das sehr überschaubar 🙂

    Mein Lösungsansatz mit PQL, wenn ich den User kenne
    [ u.DefaultCaseType | UserTable u | u.UserPK=[UserPK] ]

    Das gibt dir den CaseTypePK des Users wieder ….

    • This reply was modified 5 years, 12 months ago by Timm.
    #2969
    Stefan Reichelt
    Participant

    Sicher, dass u.DefaultCaseType funktioniert? Wenn nicht, würde ich es eher über ein neues Feld “Virtual.InboundCaseType” lösen und den Falltyp bei Anlage per Mail dort separat hinterlegen. Dann kannst du das PQL ungefähr so stricken:

    [u.Virtual.InboundCaseType.CaseTypePK|User u|u.Id='[UID]’]

    UID (U geht natürlich auch) steht hier übrigens für den Mailbenutzer, den du im Configfile des Application Servers mitgegeben hast. Und genau dort wäre ja der Standardfalltyp zu hinterlegen.

    Noch etwas zum allgemeinen Verständnis: Diese “Kürzel” sind nicht vorgegeben, sie sind lediglich ein manuell vergebener Alias für das Objekt. Du kannst auch “CaseType Schinkennudel” schreiben und dann per Schinkennudel.Id die Falltyp-ID anzeigen (sorry, ich komme gerade aus der Mittagspause).

    #2972
    Timm
    Member

    Hi,
    DefaultCaseType funktioniert wenn du es per PQL setzt ich mache es anderer Stelle mit diesen Werten (in der DB steht in diesem Feld ja der PK des CaseTypes)

    Das heißt für History-Trigger geht es nicht.

    Gruß,
    Timm

    #2973
    Stefan Reichelt
    Participant

    Sicher, aber ohne .CaseTypePK wird normalerweise das ganze Objekt zurückgegeben, was nicht immer gewollt ist. Die Frage war eher, ob das PQL hier funktioniert, obwohl der DefaultCaseType nicht direkt in der Usertabelle liegt, sondern in UserSDMSettings. Wir verwenden dieses Feld überhaupt nicht, deshalb war ich mir da unsicher…

    #2974

    [ u.DefaultCaseType | UserTable u | u.UserPK=[UserPK] ] funktioniert leider nicht.
    Nutzt du ihn im Update oder Insert?

    #2976

    So etwas funktioniert auch nicht:
    [u.DefaultCaseType|UserTable u, CaseTable t|t.CasePK=[CasePK] AND t.Responsible.UserPK=u.UserPK]

    Kann es sein, dass Falltyp = dem Kram nicht funktioniert? (Kann in der Zuweisung nicht runter auf PK) …

    #2977

    Ein Stück weiter … PK habe ich jetzt:
    [u.DefaultCaseType|UserSDMSettings u| u.UserPK=[Responsible.UserPK]]
    Es taucht jedoch der Fehler auf ‘could not resolve property:UserPK’

    Jemand eine Ahnung?

    #2978

    Im SQL funktioniert es:

    select u.default_case_type_pk from User_SDM_Settings u where u.user_pk=’83488369′

    Brauche einen Übersetzer …

    #2980
    Stefan Reichelt
    Participant

    Jetzt wird es langsam unübersichtlich…

    Dein SQL funktioniert natürlich, aber hier setzt du einen richtig ermittelten UserPK voraus, außerdem kennt PQL/HQL das Feld default_case_type_pk in dieser Tabelle nicht. Dort gibt es eben nur das Objekt DefaultCaseType. Eine Frage ist für mich: Ist denn [Responsible.UserPK] zu diesem Zeitpunkt überhaupt bekannt? Was sagt denn das TriggerTrace.log dazu? u.UserPK funktioniert so vermutlich auch nicht, weil du immer erst auf das Objekt joinen musst. Wie das heißt, musst du im EM nachsehen (ich hab gerade kein POB dabei). Vermutlich ist es einfach nur User, also u.User.UserPK.
    Bitte beachte auch meine Erläuterungen weiter oben, ich schlage stattdessen ‘[UID]’ bzw. [U] vor. Ich denke immer noch, dass es mit einer neuen Spalte in der Usertabelle einfacher wäre.

    Außerdem gehe ich immer noch davon aus, dass u.DefaultCaseType nicht funktioniert (gleiche Regel wie oben: Erst der Join auf das Objekt, dann noch ein Feld mitgeben). u.DefaultCaseType.CaseTypePK sollte durchaus gehen. Ansonsten musst du weiter runter tauchen, also ungefähr so (ich kombiniere mal meine Vorschläge):

    [ct|CaseType ct|ct.CaseTypePK=[u.DefaultCaseTypePK.CaseTypePK|UserSDMSettings u|u.Id='[UID]’]]

    Falls es auch mit dem PK-Wert klappt (manchmal geht das wie gesagt auch), lass einfach die Klammer außenherum weg:
    [u.DefaultCaseTypePK.CaseTypePK|UserSDMSettings u|u.User.Id='[UID]’]

    #2982

    Hut ab, Stefan, dass du in meinen Posts noch durchgeblickt hast!
    Dafür gibt es jetzt die von mir präferierte Lösung:
    [u.DefaultCaseType.CaseTypePK|UserSDMSettings u| u.User.UserPK=[Responsible.UserPK]]
    Einfach beim Insert Case hinterlegen und der Falltyp wird gesetzt.

    Tausend Dank für eure Unterstützung!

    Erledigt.

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.