I am filtering my Workflows with Conditions. I also use dynamic participants to assign users to workflow tasks.
I only want to able to start a workflow on an itemRevision if a dynamic participant $TestParticipant that was assigned to the itemRevsion is the same as the actual logged in user.
Any suggestions which expressions i need to use to accomplish that?
Thanks for your help!
Solved! Go to Solution.
I've not tried this myself, but there is an operation fnd0IsParticipant defined on ItemRevision that looks like it matches your requirement;
Thanks for the reply jonathan
i tried to use the fnd0IsParticipant Operation but haven't been successful. My question on this is: What is meant by "participantTypeName". Is it the name of the Participant BusinessObject?
I tried the following expression:
In the meantime i tried another way, with a compound property that contain the user_id of my partipant which i can then compare with the UserSessions user_id, but i think this is only possible for one participant and not for many.
So i am still interested in finding a solution using fnd0IsParticipant.
There are a few of the out of the box change conditions that use this operation.
In these examples it's the name of the participant type, so it looks like you are providing the correct argument.
I'll try it on a development system I have and see if I can get it working.
Hi @BB_ . I've tried this on a Teamcenter 11 (188.8.131.52(20181019.00)) 64-bit system as follows;
My results are as follows;
If I select a single ItemRevision...
If I select multiple ItemRevisions...
So for multiple ItemRevisions all of them must match the condition for the template to be available.
Note that the check is for the entire profile, not just the user id, so the login user, group, and role must match that specified in the participant.
If you only want a check for the user irrespective of their current group / role then this operation won't be suitable.
If that is what you want to do then you can get part of the way with a bit of BMIDE kung-fu.
Function::INLIST(u.user_id, o.participants, "jm4_user_name")
The participants runtime property of ItemRevision gives you all the participants. This expression compares the current users user_id with the compound property each of the participants, and returns true if it finds a match.
The caveats to this are;
If you want an equivalent of the current fnd0IsParticipant that only checks the user for validity then you'll probably need to reach for the C compiler, raise an ER, or both.
Thank you for your affort jonathan!
That really helped me out. It is now working for me in the same way as it does for you. I have used Teamcenter 12 (12.0(20180710.00)) 64-Bit for testing by the way.
Especially the second way with the compound property is interesting even though one can't specify a participant there.
I was wondering if there is a way to place the compound property directly on a participant so that the Function::INLIST queries only this participant type and not all participants, but then i noticed that Function::INLIST only works for arrays of parameter type UNTYPED_REFERENCE (2nd parameter) - not all properties are array so this won't work.
Its me again
I have a new Use-Case that i try to solve and which seems to be even more difficult.
I don't want to assign a person as a participant now i want to assign a role for example "engineer" to a participant. So that all users that are in this role "engineer" can see a Workflow task in their Worklist.
The question is if there is any OOTB solution to compare if the logged in user (only user_id is nessesary) is assigned to that role in the organisation structure. (I think this one is even more difficult, because if you assign a role (resource pool) to a participant there is no comparable user_id)
If anyone has an idea, let me know.
I think that fnd0IsParticipant doesn't help in this case as it doesn't seem to handle participants that don't resolve down to a given user. i.e. wildcard user and role always return false.
That's probably worthy of an ER as it's the kind of thing companies want to do.
You may be able to get away with the compound property trick again.
You can compound Participant.fnd0AssigneeRole / Role.role_name to give you the name of the participant role.
UserSession already has a role_name compound for the logged in user role.
Your condition could be similar to before, but checking the role_name.