We lacked a proper definition for dynamic template mappings in the package spec, and package developers (and the initial import scripts) assumed to follow the same conventions used in beats. This was not properly supported by the spec or fleet, leading to unexpected mappings (elastic/kibana#129344).
Beats-like behaviour was implemented in Fleet in elastic/kibana#137772, to support the convention currently used.
Additionally, it was assumed that any field with wildcards in its name is also a dynamic template, even if it doesn't have type: object, to avoid issues like elastic/beats#32577, more common in integrations than in beats. This was implemented in fleet in elastic/kibana#137978.
Check that these conventions are properly defined in the package spec, and document them in the descriptions of the involved fields.
We lacked a proper definition for dynamic template mappings in the package spec, and package developers (and the initial import scripts) assumed to follow the same conventions used in beats. This was not properly supported by the spec or fleet, leading to unexpected mappings (elastic/kibana#129344).
Beats-like behaviour was implemented in Fleet in elastic/kibana#137772, to support the convention currently used.
Additionally, it was assumed that any field with wildcards in its name is also a dynamic template, even if it doesn't have
type: object, to avoid issues like elastic/beats#32577, more common in integrations than in beats. This was implemented in fleet in elastic/kibana#137978.Check that these conventions are properly defined in the package spec, and document them in the descriptions of the involved fields.