Install Status for Hardware CIs (e.g. Pending Install) is mapped from Asset to CI but not mapped from CI to Asset despite the field being commonly used on Hardware CIs

Install Status for Hardware CIs is mapped from Asset to CI, but is not mapped from CI to Asset. e.g. An Asset set to In Stock/Pending Install will update the CI install_status as Pending Install, but if that is set on the CI, the Asset is not updated to match.

The current design assumes Hardware CIs (cmdb_ci_hardware and extending classes) will only be using the Hardware Status [hardware_status] and Substatus [hardware_substatus] fields, but these do not include any of the values useful for install status, such as 'Pending Install, and so it is common for the install_status field to also be used on Hardware CIs.

For non-Hardware CI classes, this will map in both directions.

Note: Features such as Event Management and Change Management use this field for CIs that are 'In Maintenance', regardless of whether they are Hardware CIs or not, which out to be mapped to the related Asset.

1. Note that there is an out-of-box 'Asset CI Install Status Mapping' with Sync Direction = Both for:
   Asset State/Substate: In Stock/Pending Install <-> CI Status (install_status): Pending Install
   
   
2. Create a new Computer CI (/cmdb_ci_computer.do), setting CI Status (install_status) as Pending Install
   
   
3. Click through to the related asset that had been automatically created. Note that Asset State/Substate is In use/None
   
   
4. Set that Asset State/Substate to In Stock/Pending Install and the CI will have Status (install_status) updated to Pending Install
   
   

After carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address this issue in any current or near future releases. We do not make this decision lightly, and we apologize for any inconvenience.

As a workaround, the OOB AssetAndCISynchronizer Script Include could be customized to piggy-back the additional field change on the insert/update already being done by the 'Create CI on insert' or 'Update CI fields on change' Business Rules.
Creating a Business Rule on the asset to update the CI is not advised, as this usually leads to nested updates and recursion, as the other OOB business rules in relation to Asset to CI synchronization will already be making updates at the same time.

Below is the recommended change for the AssetAndCISynchronizer Script Include to give precedence to one column over the other. By default, if a CI is of type Hardware, hardware_status (Hardware status) and hardware_substatus (Substatus) fields are given precedence over install_status (Status) field.

Current API code:

_inferAssetStatuses : function(ci, asset, asyncUpdate) {
    // HW statuses take precedence over CI statuses
    if (this._isHardwareCI(ci)) {
        if (!ci.hardware_status.changes() && !ci.hardware_substatus.changes() && !asyncUpdate)
            return 0;
        return this._inferAssetStatusesHardware(ci, asset);
    } else {
        if (!ci.install_status.changes() && !asyncUpdate)
            return 0;
        return this._inferAssetStatusesBase(ci, asset);
    }
},

Change the code to:

_inferAssetStatuses : function(ci, asset, asyncUpdate) {

    var precedenceColumn = "install_status"; //Value can be either "install_status" or "hardware_status"

    // HW statuses take precedence over CI statuses
    if (this._isHardwareCI(ci) && precedenceColumn === "hardware_status") {
        if (!ci.hardware_status.changes() && !ci.hardware_substatus.changes() && !asyncUpdate)
            return 0;
        return this._inferAssetStatusesHardware(ci, asset);
    } else {
        if (!ci.install_status.changes() && !asyncUpdate)
            return 0;
        return this._inferAssetStatusesBase(ci, asset);
    }
},

Below are the different mappings between status fields:

1. Asset to CI
2. Asset to Hardware
3. CI to Asset
4. Hardware to Asset

#1 and #2 work fine, whilst only one of #3 or #4 currently can be used.