Hi Scott,
That's a very interesting scenario I have not thought of my self but is so very valid.
I would think that the best way to handle this would probably be to go into the code for your destination rule and do code for it...
Potentially something like this: You will see there is an "AddUsers" helper method in the code for the destination rule. In there you will see a loop through all destination users where you can add this one if statement to filter out the originator.
foreach (string destination in destinations)
{
if (destination != K2.ProcessInstance.Originator.FQN)
K2.Destinations.Add(SourceCode.KO.DestinationType.User, destination);
}
I have not tested this my self and you might have to use a different property on the Originator, but that's the general idea...
HTH,
G
Good deal. One other question, when would BP overwrite my custom code for this section when using the designer?
Thank you,
Scott
Another possibility would be to create a custom ServiceObject to do this. The method in the object could accept an AD Group and the Originator FQN. The SvO would then handle the resolution and comparison and return a list of all appropriate identities. You could then create a SmartObject that utilizes this ServiceObject. With the SmartObject you could then the drag and drop UserID property returned from the List method it into the Destination Rule (this will prompt you to then map in the group name and originator FQN).
This creates slightly more work, but the benefits are:
1. Reusability. You can easily reuse this service/smart object in any activity in any process.
2. The code is outside of the process, so no chance of it being mistakingly overwritten or deleted.
HTH.
Hi Scott,
This is one of the cool things about the WF based wizards is that even if you re-run the destination rules wizard it will not over write your custom code behind it. The only time when it will be over written (as far as I know) is if you right-click on an activity and select "update design templates".
Ciao,
