Backwards Compatibility Exceptions¶
10.6(3) Exceptions
Prior to 10.6(3), the SyncTo hierarchy of the user in the Provisioning Status was set to the hierarchy where the User is created. Whenever the user is moved up or down the SyncTo was updated to the hierarchy where it is moved. To move subscribers between Sites, the SyncTo hierarchy behavior has been changed in a backwards incompatible way. The SyncTo Hierarchy focuses on updating the syncTo in ProvisionalStatusDAT when the user changes from a Manual user to a Subscriber user pushed to a Cisco Unified Communications Manager. In 10.6(3) the strategy is changed as follows:
Manually created Users (User Management not Subscriber Management) have the SyncTo hierarchy set to the hierarchy the user is created.
Manually created Users (User Management) that are pushed to Cisco Unified Communications Manager (becoming a Subscriber) from Customer or Site has their SyncTo hierarchy updated to that of the Cisco Unified Communications Manager. Note:
If the user SyncTo hierarchy is above the Cisco Unified Communications Manager hierarchy when it was created, then the SyncTo does not change and remains at the upper hierarchy.
Manually created Subscribers (Subscriber Management) have there SyncTo hierarchies set to to that of the Cisco Unified Communications Manager.
LDAP users are not affected (do not have their SyncTo hierarchy changed).
If a user is created on an intermediate node or site directly (either manually or through QuickAddSubscriber) and then pushed to Cisco Unified Communications Manager, the user is scoped only to the hierarchy where he or she was created.
10.6(1) Exceptions
The following changes in Cisco Unified Communications Domain Manager may impact API backwards compatibility with the previous version:
- Customer Management - Customer name change is now allowed.
- Unicode - Customer names may not have spaces.
- Localization - Language codes are now four characters.
10.1(2) Exceptions
The 10.1(2) release is not backwards compatible with the 10.1(1) release.
11.5(2) Exceptions
From 11.5.2 onwards for /api/relation/Subscriber
:
- The API URL
cached
parameter on the Subscriber list (/api/relation/Subscriber/
) will not be honoured. Data presented to the API will always display cached information and will not refresh the information from the device during a list query withcached=false
. - The API URL
summary
parameter on the Subscriber list (/api/relation/Subscriber/
) will not be honoured. Data presented to the API will always display summarized information and will not display full CUCM User data withsummary=false
. - The API parameter
traversal=up
on the Subscriber list (/api/relation/Subscriber/
) will not be honoured. Data presented to the API will default to display resources down the hierarchy tree withtraversal=up
.
The following attribute name changes have been made to the Subscriber
(/api/relation/Subscriber/
) list view:
Release 11.5.1 ES1 | Release 11.5.2 |
---|---|
firstName | firstname |
lastName | lastname |
phoneProfiles.profileName | extension_mobility |
associatedDevices.device | phone1, phone2, phoneN… |
summary_device | device |
(not present in 11.5.1) | user_type |
(not present in 11.5.1) | entitlement_profile |
(not present in 11.5.1) | hierarchy_friendly_name |
(not present in 11.5.1) | single_number_reach |
(not present in 11.5.1) | voicemail |
(not present in 11.5.1) | webex |
11.5(2) and 11.5(3) Exceptions
Releases 11.5(2) and 11.5(3) are not backward compatible
for delete operations on /view/HcsDeleteSiteVIEW/
For example, given:
- a POST action
- with Request Headers containing ‘X-Version’: u’11.5.3’`
- to endpoint
/api/view/HcsDeleteSiteVIEW/
- and Payload:
{"site_hn": "<site hierarchy name>",
"removeMisc2": true,
"removeMisc1": true,
"removeDp": true,
"setCucmUserLocal": true,
"removeRole": true,
"removeUsers": true,
"removeSubMgmt": true,
"purgeDevices": true,
"deleteSite": true,
"purgeUsers": true}
the following required fields are not backward compatible:
confirm
target_hierarchy