Steps to reproduce:

1. Use a Zabbix version where commit DEV-4644 (04814ba7ba0) is included (observed on 7.4.14 and newer).
2.  Create or use an existing template that has one or more linked parent templates.
3. Navigate to: Data collection → Templates
4.  Open any template containing linked templates.
5. Click "Clone".
6. Complete the clone operation and submit the form.
7. Open browser developer tools and inspect the form serialization process using: template_edit_popup.form.getAllValues()
8. Observe the generated value for the "templates" field.

Result:
The clone operation fails.
During form serialization, linked templates are converted into a sparse Javascript array.

Example:
Template contains a linked template represented internally as:
    templates[10887] = "10887"

The resulting serialized object contains:
    templates.length = 10888
    Object.keys(templates) = ["10887"]

JSON serialization produces:
   [null,null,null,...,"10887"]
instead of a dense array containing only the linked template identifiers.

As a consequence, the request sent to template.edit contains an invalid structure for the "templates" field and the operation is rejected by backend validation.

The issue was traced to:    ui/js/fields/class.field.array.js -> CFieldArray.getInnerValue()
The current implementation builds the array using:
    result[key] = value;
When numeric identifiers are used as keys, Javascript creates a sparse array whose length becomes equal to the highest identifier plus one.

 Regression analysis identified the behavior change introduced by:
    DEV-4644
    Commit 04814ba7ba0
Description:
    "fixed inline validation to display errors for array fields and detect correctly if changed"

Comparison with the previous implementation shows that older versions constructed dense arrays using push(), while newer versions preserve numeric keys and therefore generate sparse arrays.

Expected: The "templates" field should be serialized as a dense array containing only the linked template identifiers.

Example:   ["10887"]  and not:    [null,null,null,...,"10887"]

Template cloning should complete successfully regardless of the numeric value of linked template IDs.

Additional observations:

• The issue was not observed on 7.4.13.

• The issue is reproducible on versions containing DEV-4644.

• The behavior originates on the client side before the request reaches backend validation.

• The problem appears whenever CFieldArray processes fields whose names contain large numeric identifiers.

• The issue may affect operations other than template cloning wherever CFieldArray is used with numeric array keys.

• Root cause appears to be the change from dense-array construction using push() to indexed assignment using result[key] = value.