VMware Cloud Community
craigso
Enthusiast
Enthusiast
Jump to solution

Custom Properties not being passed in Event Broker payload? [Permissions?]

thank you for taking the time to read this post!

We recently ran into an issue where custom property values are not getting passed to vRO via the event broker/subscriptions. In our case we have a VM provisioning blueprint with a custom form. It has a few elements (check boxes and text fields) on it that take user input and store the values into custom properties. These properties get passed via the payload to vRO and we take actions on their values.

While this has been working great for the our team, once we hand the form off to a non-administrative vRA user to consume, the properties are sent, but the user inputted values are not. Initially I thought there was something wrong with our blueprints so I recreated the blueprint only adding a few raw elements to test the payload. (shown below)

Properties:

pastedImage_1.png

Blueprint/custom form:

pastedImage_0.png

We then have a event subscription to trigger when a VM is successfully provisioned.

pastedImage_2.png

As I mentioned above, this configuration works great for an administrative user. If a normal user with permissions to simply run the blueprint requests a VM, the properties values are not passed. Here are the log runs which show the payload properties for admin vs non-admin:

admin user:

2019-07-10 14:43:19.000 -07:00DEBUGvCAC VM properties :

Base.Description :

Base.Hostname : CAS-vRATest-2

Base.InstanceNumber :

Base.NetworkZone :

Base.OU : CAS

Base.ServerName :

Cafe.Shim.VirtualMachine.TotalStorageSize : 40

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.BuildingMachine : *

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineActivated : *

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned : *

Hostname : CAS-vRATest-2

UO.IS.TDX-AdditionalNetworkingDetails : test

UO.IS.TDX-AdditionalStorageDetails : test

UO.IS.TDX-RequestAdditionalNetworking : true

UO.IS.TDX-RequestAdditionalStorage : true

UO.IS.TDX-RequestFirewallRuleDescription : test

UO.IS.TDX-RequestFirewallRules : true

UO.IS.TDX-RequestOther : testing

UO.IS.TDX-SupportedOUs : IS,CAS,CTL

UO.IS.TDX.Create_Ticket : True

non admin:

2019-07-10 14:04:04.000 -07:00DEBUGvCAC VM properties :

Base.Description :

Base.Hostname :

Base.InstanceNumber :

Base.NetworkZone :

Base.OU :

Base.ServerName :

Cafe.Shim.VirtualMachine.TotalStorageSize : 40

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.BuildingMachine : *

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineActivated : *

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned : *

Hostname : cas-vRAtest1

UO.IS.TDX-AdditionalNetworkingDetails :

UO.IS.TDX-AdditionalStorageDetails :

UO.IS.TDX-RequestAdditionalNetworking :

UO.IS.TDX-RequestAdditionalStorage :

UO.IS.TDX-RequestFirewallRuleDescription :

UO.IS.TDX-RequestFirewallRules :

UO.IS.TDX-RequestOther :

UO.IS.TDX-SupportedOUs : IS,CAS,CTL

UO.IS.TDX.Create_Ticket : True

The values that do get passed in both log runs are static defined in the custom property definition. The values that are missing are user inputted values.

Any idea why we are seeing this behavior? Ideally the properties would get passed even for a standard user.

1 Solution

Accepted Solutions
daphnissov
Immortal
Immortal
Jump to solution

I'm laughing a little bit because I can't believe the irony of this situation. I literally just figured this out for a customer that was having the exact same issue. vRA 7.4, using custom forms, custom property values present in the payload for business group admins but absent for business group users. Fortunately for us both, I figured out a fix. Unfortunately, however, this isn't even fixed in hot fix 12, which is the latest as of this writing.

TL;DR == Change your custom properties within your blueprint to show in request = yes. On your custom form, make them required fields (change from "no" to "yes"). Once you've made this change, those values should get passed into the vRO payload for regular business group users.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.

View solution in original post

17 Replies
daphnissov
Immortal
Immortal
Jump to solution

I'm laughing a little bit because I can't believe the irony of this situation. I literally just figured this out for a customer that was having the exact same issue. vRA 7.4, using custom forms, custom property values present in the payload for business group admins but absent for business group users. Fortunately for us both, I figured out a fix. Unfortunately, however, this isn't even fixed in hot fix 12, which is the latest as of this writing.

TL;DR == Change your custom properties within your blueprint to show in request = yes. On your custom form, make them required fields (change from "no" to "yes"). Once you've made this change, those values should get passed into the vRO payload for regular business group users.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.

qc4vmware
Virtuoso
Virtuoso
Jump to solution

Is this a 7.4 issue only or does it also exist in 7.5?

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Well, I know it's in 7.4, but based on OP it would appear to be 7.5 or 7.6. That's what I'm interested to know.

craigso
Enthusiast
Enthusiast
Jump to solution

Currently running 7.6.0 - Sorry should have included that in the original post.

Just got to work, so I'll test this really quick and report back. Thanks for the quick replies as always!!

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

After setting the properties as show in request, the values did indeed get passed to the payload for a normal user without any admin rights or special roles.

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

I should note, I didn't have to mark the fields as required. Simply 'show in request' did the trick.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Good to know, so it is the exact same issue I encountered. Normally, in a custom form, if you selected the option to show in request, it marks that field as required = yes. In 7.6 it may do this automatically, otherwise it fails validation.

Also, could you please raise an SR on this and reference the one I've already created? That SR I created is 19013641707. By having multiple, different customers raise this issue it gets prioritized higher so the chances are good we may see this addressed in a future hot fix that extends from 7.4 to 7.6.

craigso
Enthusiast
Enthusiast
Jump to solution

Opened SR# 19013699507 for this issue and referenced your open SR.

Thanks for your help!

Reply
0 Kudos
Vsure
Enthusiast
Enthusiast
Jump to solution

I'm glad an SR was opened because selecting "Show in Request" isn't an option for us because it caused some properties to return errors something to the effect of values not in allowed list.

We did find that you just need to add the users to the "Support" role of their Business Group.  No Admin rights/roles required.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

selecting "Show in Request" isn't an option for us because it caused some properties to return errors something to the effect of values not in allowed list.

It sounds like you either have an issue with your properties, or you may need one of the available hot fixes to address a separate bug. You shouldn't see that error to begin with and in custom forms it shouldn't have a bearing.

We did find that you just need to add the users to the "Support" role of their Business Group.  No Admin rights/roles required.

While that's good if it works for you, it's problematic because now those users in the support role can see/manage deployments of other users in that same group. Works for some, but not all, customers.

Reply
0 Kudos
Vsure
Enthusiast
Enthusiast
Jump to solution

Just stating the symptom isn't directly related to admin rights since you can reduce the rights to just Support role to resolve it.  I do not want to put users in the Support Role either which is why I'm glad the SR was opened.

Selecting "Show in Request" results in the following error for every custom property configured as a Dropdown.  They have a single static value configure (you can't save as a dropdown without it) that is replaced by an External Source in the Custom Form.  We are on v7.6 HF1 so there is no hotfix that resolves this.  The fix for the below error was to remove the check from "Show in Request".

Error After submitting form:

"The deployment request failed when it was sent to the server. The data specified within the request is invalid. The value for the 'IAS.Request.Build.ServerFunction' field should be among the permitted values."

Reply
0 Kudos
xian_
Expert
Expert
Jump to solution

Hmm, I've seen this error message in 7.5 using custom forms from time to time, but could not really interpret it. Did I face the same problem? 
Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

Reply from the Dev's:

From Composite Blueprint standpoint Custom Properties which are NOT 'Show in request', cannot be edited or even seen by 'Basic User'.
The difference with Custom Forms is that in the Designer whether 'Show in request' is checked or not, we're able to drag the property and display it in the form giving the impression that it can be edited by everyone. The issue is when Basic User is filling in the value and it gets filtered from request data by the Blueprint Service in the backend when executing the Custom Properties validation.

There is no workaround for this except enabling the 'Show in request' flag of the properties in the Composite Blueprint. Custom Properties are treated specifically and this is by design. Except describing this in documentation/KB there is not much we can do.

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

I have also provided feedback that show in request also marks the field as required without actually marking it as required on the custom form. As a result the form can be submitted without any input and the request will fail with something like this:

The deployment request failed when it was sent to the server. The data specified within the request is invalid. The 'VMComponent~UO.IS.TDX-RequestFirewallRuleDescription' field is required.

Our workaround to this so far is to set the default value of the field to a blank unicode character. It works, but it's not a great solution.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

If you go back into the custom form after changing the "show in request" flag from no to yes, the custom form should look at the current blueprint settings and attempt to validate the fields. It'll then tell you that it's required and won't let you save it until you change that field to required = yes. This is probably why it's allowed to fail in the request if you didn't perform this step.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

I received a pretty comprehensive response from engineering today after a PR was opened on this issue. The response indicates that this is intended behavior and was a result of security concerns. Full text below:

1. This behavior is not a bug, this behavior is by design. 

2. The change to remove hidden properties in a request submitted by a basic user was made in an earlier version in response to customer complaints that there was a security hole risk in vRA that allowed users making requests via vRO or REST to add request properties that were disallowed through the UI.   In the UI, a basic user does not have access to any properties not marked show-in-request in the blueprint (i.e., the properties tab is hidden from them).  Customers viewed this as a must-fix security hole. This is what drove the change.

3. Moving forward,  requests submitted with a hidden property by a basic users, will not be passed in the payload.  Only requests submitted by members of the Group Manager and the Support User role can pass the value of a hidden property in the request payload. 

4. In summary, if you wish to use hidden properties in your blueprints, you will need to add those users to either the Support User role or the Group Manger role.  You may also select the "Show in Request" box so that the value of the hidden property is passed in the payload.

craigso
Enthusiast
Enthusiast
Jump to solution

I also received another response from the dev team.

From Composite Blueprint standpoint Custom Properties which are NOT 'Show in request', cannot be edited or even seen by 'Basic User'.

The difference with Custom Forms is that in the Designer whether 'Show in request' is checked or not, we're able to drag the property and display it in the form giving the impression that it can be edited by everyone. The issue is when Basic User is filling in the value and it gets filtered from request data by the Blueprint Service in the backend when executing the Custom Properties validation.

There is no workaround for this except enabling the 'Show in request' flag of the properties in the Composite Blueprint. Custom Properties are treated specifically and this is by design. Except describing this in documentation/KB there is not much we can do.

This makes sense to me.