It looks like the group object returned by Entity.getObject doesn't actually include the membership at all.   So maybe we will use a rest call to go get that from IG, then craft an array of members, then throw that into the assignee on the approval activity?

Hello,

I didn't try it myself for this case, but try: "Entity.get('group', '49', ['members']). According to the documentation it should work like that:

https://www.microfocus.com/documentation/identity-governance/3.7/workflow-admin-console/bookinfo.html

We have the same issue currently with a multi-value attribute from the user and are also fighting to get all the results. I will let you know if we find an solution.

BR

Tobias

For us the following call worked to get a multi-value attribute from a user (attributename = ext_ipgIGReviews). We also got the supervisor back (don't know why)

JSON.stringify(Entity.getObject('user', flowdata.get('review/userId'), ['ext_ipgIGReviews'])) ->

We used this call in a log activity. So, we had to use "Entity.getObject" and put the attribute in " [ ] "

BR

Tobias

EDIT:
For information only. The response is then an array and has a JSON entry.
If you only want the JSON, an "(Entity.getObject('user', flowdata.get('review/userId'), ['ext_ipgIGReviews'])[0]" was enough for us

Hrm, I still can't for the life of me assign an IG group as an approver in Group Approval mode or normal. I've tried the group ID's, I've tried using the Entity.getObject call (which I can confirm returns stuff), and thrown it into JSON.  

--Jim

Ahhhhhhhhh, I've realized that when you assign a group as an assignee on a approval activity, it uses the group ID from source as the 'full name' of the approver, and the db column to store that is only 32 chars, so if you group id is too big, it fails.   When I shrink my group id's, its all good!

That is a very interesting problem. At what point do you shrink the group ID, is it directly when importing the group in a transformation script or can you do it in the workflow?

Good to hear that the problem has been solved!

I shrink the group ID during Identity collection.  I was using the DN of the group coming from eDiras the Group ID from Source, but I changed it to the cn.  In my case all my "IG Groups" are in the same eDir container, so I know they are unique.  In a larger deployment spread across multiple containers, that might be a problem since cn's could be duplicated.

If you tried to fix it in the workflow, it would be too late.  The workflow need to store the Group ID from Source in the task table, and it can't if it's too long.  So, for now, the only workaround that I can think of is to change the Group as you pull it in via the identity collection.

--Jim

Thank you for the information!