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 with cached=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 with summary=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 with traversal=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