none
CRM 4.0 Fehler bei Datensatz per Workflow zuweisen

    Frage

  • Hallo Community,

    ich habe ein etwas seltsames Problem. Einer unserer User legte Kontakte zentral an und soll diese dann per Workflow (zwecks Verteilung nach PLZ etc.) den Kundenberatern zuordnen. Er darf nur seine eigenen Kontakte sehen/bearbeiten/zuweisen etc. Das Zuweisen über den entsprechenden Button funktioniert problemlos, aber wenn das Zuweisen Teil eines Workflows ist, bricht dieser mit einer Fehlermeldung ab und im Trace bekomme ich folgenden Fehler:

    Crm Exception: Message: SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 3af72235-583f-e011-98d0-404e57434401, OwningUser: e54e3df0-2b75-e211-b98e-3c4a92f1f849 and CallingUser: 51920228-1e27-e211-a375-3c4a92f1f849, ErrorCode: -2147187962

    Ich habe bereits einen Workflow gebastelt, der nur aus dem Zuweisen besteht und auch hier tritt der Fehler auf. Bekommt der User Leserecht für alle Kontakte funktioniert der Workflow, aber das ist in der Praxis leider nicht möglich.

    Hat jemand eine Idee woran es liegen könnte, dass das Zuweisen per Button funktioniert aber nicht im Workflow?

    Es handelt sich um CRM 4.0 auf UR 21.

    Viele Grüße,

    Bastian

    Montag, 10. Juni 2013 19:50

Alle Antworten

  • Hallo Bastian,

    der Workflow läuft in einem anderen Benutzerkontext im Vergleich zu dem manuellen Zuweisen.

    Schöne Grüße,

    Nils Frohloff

    Montag, 10. Juni 2013 22:01
  • Hallo Nils,

    vielen Dank für den Hinweis. Hast du einen Vorschlag, wie ich das Zuweisen per Workflow ermöglichen kann ohne dem Nutzer gleich weitreichende Leserechte auf die Kontakte zu geben?

    Viele Grüße,
    Bastian

    Dienstag, 11. Juni 2013 06:20
  • Vielleicht noch ein Zusatzhinweis: Der Workflow weist den Kontakt schon entsprechend zu, aber bricht dann die weitere Verabeitung ab. Am eigentlichen Zuweisen scheint es also nicht zu liegen.
    Dienstag, 11. Juni 2013 07:38
  • Hast du mal gepüft in welchem Kontext der Workflow ausgeführt wird?

    Es müssen die folgenden Eigenschaften erfüllt sein:

    1. Der User, in dessen Kontext der Workflow ausgeführt wird, muss das Recht haben die Aktion durchzuführen (also das Zuweisen Recht haben)

    2. Der User, der neuer Besitzer, der Datensatzes wird, muss min. Leserechte auf den Datensatz haben, da er sonst nicht Besitzer werden kann. Das Gleiche gilt auch für alle Datensätze, die durch die Kaskadierung mit den Besitzer wechseln! Also wenn euer System so eingestellt ist, dass z.B. auch die Aktivitäten, Angebote etc. den Besitzer wechseln, dann muss der Empfänger natürlich auch Leserechte auf diese Entitäten haben.

    Viele Grüße,

    Nils Frohloff

    Dienstag, 11. Juni 2013 08:56
  • Der Workflow läuft ganz normal im Namen des Benutzers, der den Datensatz zuweist und die von dir in 1. und 2. beschriebenen Rechte sind auch vorhanden.

    Das ist irgendwie ein Problem mit den Rechten des Zuweisenden, da alles problemlos funktioniert, wenn dieser das Recht hat alle Kontakte zu lesen (was aber in der Praxis leider nicht möglich ist).

    Ich habe einen Workaround gebastelt: Am Anfang des Workflows gibt sich der Besitzer des Kontakts selber noch mal eine Freigabe auf den Kontakt und dann funktionieren die Dinge wie das Zuweisen etc. ohne Abbruch. Am Ende des Workflows nimmt sich der ehemalige Besitzer die Freigabe wieder weg und alles passt. Etwas umständlich, aber führt zum gewünschten Ergebnis.

    Dienstag, 11. Juni 2013 11:29
  • Hallo Bastian,

    hast Du Zugriff auf die Datenbank? Falls ja und falls Du noch wissen willst was die genaue Ursache ist gehst Du wir folgt vor.

    1. Mit select * from systemuserbase where systemuserid='51920228-1e27-e211-a375-3c4a92f1f849' das sagt Dir wer der "CallingUser" ist.

    2. Mit select * from systemuserbase where systemuserid='e54e3df0-2b75-e211-b98e-3c4a92f1f849' das sagt Dir wer der "OwningUser" ist.

    Crm Exception: Message: SecLib::AccessCheckEx failed. sagt ganz unmissverständlich das ein Recht einem der beiden Systemuser fehlt.

    Wenn Du wissen willst welches Recht fehlt kannst Du die Details mit einem Trace aufzeichnen. Da stehen dann besser lesbare Meldungen drin. Wie missing privRead... und eine ID. Die ID kannst Du in der Datenbank finden und bekommst einen Idee welches Recht gesetzt werden muss.

    Ich hoffe Du hast jetzt eine grobe Idee. Wenn Du nicht weiter kommst mit schreib einfach noch mal.

    Grüsse

    Thomas

    Mittwoch, 12. Juni 2013 06:52
  • Hallo Thomas,

    vielen Dank für die Infos. Natürlich bin ich immer noch an den Hintergründen der Sache interessiert :)

    Bei den Usern handelt es sich, wie es sein sollte, um den Zuweisenden (OwningUser) und den Kontaktempfänger (CallingUser).

    Ich hatte auch schon gehofft, dass ich irgendwo explizit gesagt bekomme, welche Berechtigung fehlt, aber bisher habe ich da nichts gefunden. Ich hatte den Trace über das Diagtool aktiviert und dann die Protokolle für den Async Service und Webservice erhalten.

    Der Async hat als einzigen Error, dass der Workflow beendet wird mit dem Fehler:
    System.Reflection.TargetInvocationException: Folgender Fehler beim Ausführen der Methode "Compiled.Workflowafd74a3fe5d1e211b86b3c4a92f1f849.PopulateEntity": Server was unable to process request. ---> System.Web.Services.Protocols.SoapException: Server was unable to process request.

    Beim Web-Trace bekomme nur die Fehlermeldung von oben mit ObjectID, Owner und Caller ohne irgendeine PrivilegeID. Aus den SQL Abfragen, die vor dem Fehler abgefeuert werden, kann man vermuten, dass es Recht im Zusammenhang mit Contact oder Activitypointer ist, aber das habe ich schon vorher vermutet, da ja alles funktioniert, wenn der Owner das Leserecht auf alle Kontakte bekommt. Es ergibt für mich aber irgendwie keinen Sinn, wenn eine Zuweisung im Workflow nur funktioniert, wenn der Owner alle Datensätze dieses Typs sehen darf. Dann könnte man über einen Workflow ja nie etwas "wegdelegieren".

    Grüße,
    Bastian

    Mittwoch, 12. Juni 2013 10:42