What triggers this problem analyzer?

You can track history for fields, name fields and record types of standard and custom objects. To do this, history tracking must also be enabled on the parent object.
(N.B. some standard objects have history tracking enabled as default.)

We'll look to see if the field, name field or record type has history tracking enabled and look to see if the parent object is in the target, and if it is, we'll check if it has history tracking enabled too.

What problem is it solving?

If the parent object is in the target, and it has history tracking turned on - there's no problem!

If the parent object hasn't been deployed to the target yet - there's no problem!

However, if the parent object is already in the target, but history tracking is not turned on, there is a problem! 

If you try to deploy a field, name field or record type that has history tracking enabled before the parent object in the target org has history tracking enabled, the deployment will actually succeed. The target will pick up the change - you'll see an enabled checkbox in your field-specific tracking though the parent still has it unchecked.

The problem is that this change is invisible when retrieving via the metadata API, so re-running the comparison after the deployment will still return that the field tracking history of the target is set to false. Another issue is that even though the field history tracking is now set to enabled, you still can't actually track the field's history unless the parent has it enabled.

How does it work?

Rather than remove the history tracking field from the xml of the sub-component, we'll add the history tracking field to the parent object.

Did this answer your question?