vSphere Client SDK 8.0 Update 1 Release Notes
This document contains the following sections
Introduction
vSphere Client SDK 8.0.1 | 18 April 2023 | vCenter Server, build on developer.vmware.com For vSphere 8.0 Update 1 release | Last document update 17 April 2023 Check back for additions and updates to these release notes, marked New . |
About the vSphere Client SDK
The vSphere Client SDK provides sample plug-ins, tools, libraries, and documentation to help developers build user interfaces with vSphere Client extensions for vSphere and VMware Cloud.
Changes and New Features
The vSphere Client SDK 8.0 U1 offers the following
New:
features:- Ability to define action separators.
Plug-ins are now able to define separators between their menu actions. This can be achieved by specifying a new object {"type":"separator"} between the plug-in defined actions. For example:
"actions": [
{
"id": "myAction1",
"labelKey": "vm.action.label1",
"icon": {
"name": "action-vm"
},
"trigger": {
"type": "modal",
"uri": "index.html#/vm-action-modal",
"titleKey": "vm.action.modal.title",
"size": {
"width": 600,
"height": 205
}
}
},
{
"type": "separator"
},
{
"labelKey": "vm.action.label2",
"icon": {
"name": "action-vm"
},
"trigger": {
"type": "modal",
"uri": "index.html#/vm-action-modal",
"titleKey": "vm.action.modal.title",
"size": {
"width": 600,
"height": 205
}
}
},
]
- Ability to define multiple summary cards.
Plug-ins are now able to define up to 3 cards in a given vSphere object's summary view. In addition, each card can have its own icon and title. If no icon or title are provided, the default plugin icon and name will be used. This can be achieved by specifying an array of views instead of a single view in a given object's summary section. For example:
"summary": {
"views": [
{
"id": "card1Id",
"uri": "resources/card1.html"
},
{
"id": "card2Id",
"uri": "resources/card2.html",
"icon": {
"name": "card2Icon"
},
"titleKey": "card2Title"
}
]
}
- Integrated Solution Installation
Solution installer with ability to specify required vCenter Server version support. Integrated solutions can now specify which vCenter Server version they support. This will prevent users from installing the solution on a vCenter Server with lower than the specified version. To achieve this, the vmw.vsphereui.solutioninstall.requiredVcVersion property must be specified in the solution's OVF. For example:
<Property ovf:qualifiers="ValueMap{"8.0.1"}"
ovf:userConfigurable="true"
ovf:value="8.0.1"
ovf:type="string"
ovf:key="vmw.vsphereui.solutioninstall.requiredVcVersion">
<Label>Required vCenter Server version</Label>
<Description/>
</Property>
- Remote Plug-in Sample
Upgraded Angular and Clarity versions for improved security.
- Tools
The extension-registration tool now accepts a list of events. This means that plug-in registration may include a list of plug-in defined events.
For new features in the previous versions, see the
vSphere Client SDK 8.0 Release Notes
and before.Compatibility Notices
Local plug-ins for vSphere Client remain functional in the vSphere 8.0 release, but they must be upgraded for compatibility with a number of security-related changes. Local plug-ins must become FIPS-compliant and must isolate their 3rd-party libraries. Partners should migrate all local plug-ins to remote plug-ins as soon as possible.
Recently Resolved Issues
The vSphere Client SDK 8.0.1 release resolves the following issue.
- Actions are now ordered in the way they are written in the plugin.json.
- Fixed an issue where a plug-in may be shown asPartially Deployed.
- The plug-in action menus are properly live refreshed when the usershows/hidesa plug-in.
- Fixed an issue where anIncompatibleplug-in could be shown asFailed.
- The htmlClientSdk is no longer cached by the browser and does not break plug-in upgrades.
- FixedConfirmation Modallayout issues.
- Plug-in deployment will no longer fail if it is using an unknown locale. This means that adding a new supported language to the vSphere Client and the plug-in will not break the plug-in's compatibility with older vSphere Client versions.
- Fixed an issue where anIncompatibleplug-in could not be redeployed.
Known Issues and Workarounds
These are unresolved issues known at this time.
- Multiple Manifest Issue.
The
Multi Manifest
feature requires a default manifest called plugin.json. If a plug-in is using the multi manifest feature, it is required that at least one of the plug-in manifests is named plugin.json. It is recommended that the least desired plug-in manifest is named plugin.json and placed at the bottom of the array of manifests. For example:{
"manifestVersion": "1.0.0",
"manifests": [
"plugin-80.json",
"plugin-70.json"
"plugin.json"
]
}