VMware Cloud Community
tchristin
Enthusiast
Enthusiast
Jump to solution

Only vsphere.local users receive manual user action task into their inbox

Hi following my post Re: Impossible to change lease of VM with vRO where I'm trying to control lease change scenarios, I'm facing troubles about manual user actions.

I'm able to get all ldapUser people who manage the business group, and adding them to the security.assignees attribute of the user interaction item in vRO, and all people (from AD and vsphere.local) receive the mail notification about this new manual user action, but only vsphere.local users receive the task inside Inbox > Manual User Action.

For AD users, clicking on the link inside the email open the right vRA section but it's empty (using default filter "owned by me").

AD users can view the task if they change the filter "owned by" to "My tenant" but if they open the task, the content is empty...

I tried to select ldapUser manually (wokflow input) or tried to use security.group attribute and bind to an AD group but same result...

That's so sad, as this is the only thing missing for my workflow to work (after receiveing great help from SeanKohler‌).

Do you have any idea why the mapping doesn't work between vRO and vRA ?

I'm thinking about missing mapping vCACCAFEUser <> ldapUser.

Any help would be greatly appreciated !!

Tim.

1 Solution

Accepted Solutions
tchristin
Enthusiast
Enthusiast
Jump to solution

Issue resolved by upgrading to 7.2.

Can be added to the list of resolved issues.

Thanks again to SeanKohler‌.

Tim.

View solution in original post

12 Replies
SeanKohler
Expert
Expert
Jump to solution

I will be working on a similar capability early next week.  (We need to get in the middle of reservation increases with a manual user task.)  I will either run into the same problem or work around it.  If I figure it out, and nobody has yet answered, I will let you know.

Sean

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Thanks a lot Sean !

I'll try to find a workaround for this issue.

Cheers,

Tim.

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Just to add a precision, I use Active Directory over LDAP on port 389.

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Hi SeanKohler,

Do you think it could be possible to activate on the fly an approval policy so the approvers would receive a notification to let the workflow resume or stop ?

That's the only idea I found as a workaround.

Thanks for your help !

Tim.

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Same problem with approvals coming from  vRO (tested with the Library/VCACDevopsRPEngine/Gating Workflows/Approval workflow).

I'm suspecting mapping issue between ldapUser & VCACCAFEUser types as mentionned in my first post...

Reply
0 Kudos
SeanKohler
Expert
Expert
Jump to solution

Cafe Users are UIDs... but maybe.  I only have a minute right now, but I haven't forgot about this.

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Tanks a lot !

I checked the vRO log live stream and received any information about the AD users issue...

Very strange !

Reply
0 Kudos
SeanKohler
Expert
Expert
Jump to solution

Per examples I have in 6.x, you can definitely use security.group.

This is working for me in 7.

I created a simple workflow with a single manual user task (no inputs... just bindings to attributes).  In the workflow I selected an LDAP group as a value for the attribute used for security.group  (verifying that it came from the correct AD domain and not vsphere.local)  I created a quick XaaS Blueprint, published and entitled it.  Requested it... and the resulting task was created in the Manual User Action list in vRA.  It is assigned to the people in the group (of which I am one).

It works... and we just need to figure out why it isn't working for you.  In this case, I happen to ALSO have a like-named group in vsphere.local (due to some other testing I was doing).  So I will do a little more testing around that.  I would also expect that vRA would need to be able to see the group that you are assigning... meaning it has to be part of your directory sync.  If you cannot add the group in a business group Users field (for example)... it probably won't work as an assignee group in VRA.  (just a guess... more testing required)

manTask1.jpg

manTask2.jpg

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Hi Sean,

Thanks for your feedback.

I tried with the security.group and I have the same problem although the group and all his members are synced in vRA.

The only difference I can see is that you're working on 7.2.0 and me on 7.0.1...

Something strange is that all concerned users receive the email notification from vRA but impossible to act on the manual user action (as I switched to the "owned by : my tenant" view to see the request):

manual_user_action_error.png

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Hi SeanKohler,

I reproduced your test with the kind of same workfow (only one user interaction) and it still fails.

I note that the ldapUser and ldapGroup types are not natively supported in vRA as I can't find dynamic values into the form as it's possible for vCACCAFE:VCACHost and other types.

So to give some inputs I have to type username or group name and mention the domain name to let vRO find matching values.

I thinks it's something like into my lease change workflow :

var ldapUser = (Server.searchLdapUsers(vraUser.getPrincipalId().getName(), 0)[0]);

Is it the same in vRA 7.2.0 ?

Even if matching is correct in vRO, it won't send an item in the AD user or group that it can be editable (only grayed out as in the picture of my last post).

But email notifications are still correct (concerned users are notified)...

I hope that the inputs will help to find an explanation and maybe a solution 😉

Cheers,

Tim.

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Hi guys,

I still need help... please !!!

Tim.

Reply
0 Kudos
tchristin
Enthusiast
Enthusiast
Jump to solution

Issue resolved by upgrading to 7.2.

Can be added to the list of resolved issues.

Thanks again to SeanKohler‌.

Tim.