Hallo zusammen, vielen Dank für eure Antworten! Die Vorschläge sind normalerweise die Lösung zu meinem Problem. Leider, wie soll es auch anders sein, gibt es bei meinem Workflow da ein Problem.. welches ihr nicht wissen könnt.
Der WF sieht wie folgt aus:
Der Initiator (I) des Workflows befüllt ein Formular mit Daten. Unter anderem mit einem Abteilungs-Merkmal (AM)
Über SQL greife ich auf Basis des AM auf eine „Routing Tabelle“ zu. Diese enthält die Informationen, für welche Einheit welche Person (P1) freigabeberechtigt ist.
Nun können mehrere Fälle eintreten (nicht alle skizziert):
AM Eintrag des I ist richtig und keine Vertretung des P ist aktiv >> P kann freigeben >> OK.
AM Eintrag des I ist falsch und keine Vertretung des P1 ist aktiv >> P1 sieht Fehler und korrigiert AM >> Dadurch ist P1 nicht mehr freigabeberechtigt** >> P1 leitet entsprechend Schritt an den nun Freigabeberechtigten (P2) weiter. Angenommen dies führt zu Fall 1 >> OK.
Das Problem ist nun im Fall einer aktiven Vertretung.
Angenommen der AM Eintrag des I ist richtig und P1 hat eine Vertretung. Dann führt dies beim Check ** zu dem Ergebnis, dass der Vertreter nicht freigabeberechtigt.
In anderen Worten, ich habe das Problem zwischen einem berechtigten Vertreter und einem fälschlicherweise bestimmten P1 zu unterscheiden.
Aus diesem Grund hatte ich auf ein Merkmal, wie „in_substitution_for“ gehofft um den Check entsprechend zu erweitern. Da das Feld scheinbar erst nach der Freigabe des Schrittes befüllt wird hilft es mir leider nicht.
Theoretisch könnte man natürlich die Routing Tabelle um die Vertreter erweitern, was wir allerdings aus verschieden Gründen vermeiden wollen.
Weiterhin könnte man P1 dahingehend einschränken, dass das AM nicht korrigierbar ist, sondern im Falle einer falschen Eingabe der Prozess abgebrochen werden muss. Das fühlt sich allerdings auch nicht elegant an.
Falls ihr weitere Möglichkeiten seht gerne er damit! :)
** Um dies zu erkennen wird folgendes geprüft: Aktueller User = User laut Routing Table. Falls Nein >> Senden blockieren und Grund User anzeigen; Falls Ja >> Senden erlauben
Hallo Karim,
ich würde alternativ zu Timo's Vorschlag über eine PHP-Funktion, das bevorzugt über ein SQL-Element zu lösen und dann per Funktion prüfen, ob man ein Ergebnis / eine Zeile zurückbekommt. Müsste dann in etwa so aussehen:
SELECT
jobfunction,
username
FROM [JRPROD].[dbo].[JRINCIDENTS]
WHERE (jobfunction = (SELECT jobfunction FROM JRUSERJOB WHERE username = '[jr_username]')
OR username = '[jr_username]')
AND workflowid = '[jr_workflowid]'
Ich bin persönlich nicht unbedingt ein Freund von PHP-Funktionen im Dialog, da die Performance z.T. schon für Kleinkram sehr zu wünschen übrig lässt.
Viele Grüße
Jan
Hallo Karim,
eine spannende Frage, die sich glaube ich gar nicht so leicht beantworten lässt.
Wer einen Schritt erhalten hat, wird in der Tabelle JRINCIDENTS festgehalten. Dort kann neben der Rolle einer Einzelperson (#Username#) auch eine JobRouter-Rolle stehen. Auch dafür kann man ja theoretisch eine Vertretung einrichten, damit einen Person XY in der Rolle YZ vertritt.
Ich würde bei diesem Problem wie folgt vorgehen:
In einer PHP-Dialogfunktion über die WorkflowID den recipient (User oder Rolle) aus der JRINCIDENTS ermitteln und dann mit dem aktuellen User abgleichen. Bei echten Rollen mit mehreren Usern könnte man noch schauen, ob die Person selbst in der Rolle ist oder für diese Rolle Vertretung macht. nktion über die WorkflowID den recipient (User oder Rolle) aus der JRINCIDENTS ermitteln und dann mit dem aktuellen User abgleichen. Bei echten Rollen mit mehreren Usern könnte man noch schauen, ob die Person selbst in der Rolle ist oder für diese Rolle Vertretung macht.
Noch ein kleiner Nachtrag zum Feld "in_substitution_for":
Dieses wird erst gefüllt, wenn der Schritt gesendet wurde. Ich zitiere dazu mal das Handbuch: "Benutzername, der den Schritt hätte bearbeiten sollen, wenn der Schritt von einem Vertreter gesendet wurde.".