Device Management Issues Resolved
The following issues with device management were resolved in the 2023 R1 release.
| • | Binding Break Repair Requests Now Denied After “Repairs Allowed” Value Change |
| • | Illegal Characters in “Alias” in Capability Request No Longer Cause “Devices” Page Error |
| • | Devices Page Now Loading Correctly When Device Name Includes Invalid Control Characters |
| • | Corrected Default Value for Binding Break Limit |
Binding Break Repair Requests Now Denied After “Repairs Allowed” Value Change
When the option Maximum Number of Repairs Allowed (in the Producer Portal on the View Server page) was set to a new value that was less than the value for Repairs Allowed, and a subsequent repair was requested that would exceed the maximum number of repairs allowed, the repair request erroneously succeeded. This has now been fixed, and any repair request that exceeds the maximum number of repairs after a change of the Repairs Allowed value allowed fails as expected.
Illegal Characters in “Alias” in Capability Request No Longer Cause “Devices” Page Error
Previously, when the Alias field in the capability request contained multiple control characters (see note below), the Devices page did not load as expected. This issue no longer occurs.
Note:Control characters are characters that do not represent a printable character but instead serve to initiate a specific action. A control character is entered using a combination of the Ctrl key and a letter. The caret symbol (^) is used to indicate the Ctrl key. Example: ^A represents Ctrl+A.
The following control characters are not allowed in device names or the device ID:
^B ^D ^E ^G ^N ^O ^P ^Q ^R ^S ^T ^U ^W ^X ^Y ^[ ^\ ^]
Devices Page Now Loading Correctly When Device Name Includes Invalid Control Characters
Previously, when a device was created using a capability request and the “Device ID” or “Alias” field contained an invalid character, the Devices page did not load as expected.
In this release, when a device is created using a capability request, invalid characters in the “Device ID” or “Alias” field are replaced with an empty string (for example, the device name Test^BName is saved as TestName). As a result, the Devices page loads without errors.
As a side effect, when an invalid character is used in the “Device ID” or “Alias” field and subsequently removed by FlexNet Operations, the license will not be processed by the FlexNet Embedded toolkit. Revenera aims to address this issue in a future release of the FlexNet Embedded toolkit.
The following control characters are invalid and are replaced with an empty string. They should not be used when creating a device using a capability request: ^B, ^D, ^E, ^G, ^N, ^O, ^P, ^Q, ^R, ^S, ^T, ^U, ^W, ^X, ^Y, ^[, ^\, ^]
New Configuration Option
The behavior—whether invalid characters are replaced with an empty string—is controlled by a new configuration option Retain Non-Printing Characters in Device ID and Alias (located under System > Configure > Embedded Devices > Host Options). By default, this option is unselected and invalid characters are replaced with an empty string.
Customers who want to retain the original behavior (where invalid characters are not removed) are advised to select the new configuration. Customers should note that in this case, if the “Device ID” or “Alias” field contains an invalid character, the Devices page will not load correctly.
Corrected Default Value for Binding Break Limit
Previously, the configuration option Maximum Number of Binding Break Repairs Allowed for License Server (available when selecting Limit Binding Break Repairs for License Server, under System > Configure > Embedded Devices > Host Options) had an incorrect default value of 0. This has now been corrected, and the default value is 3.