Bug: Batch import creates ABP tags in Device Twin for OTAA-based device models

[Metal-Mighty]

Expected Behavior

When importing a list of devices from the provided CSV template file, the portal should check the type of device authentication before creating it, and only set values for the proper authentication method (OTAA or ABP)

Current Behavior

The portal creates OTAA devices with all properties set (with values or empty strings depending on what's provided), which causes the devices to fail loading in the LoRa Network Server due to the presence of ABP variables in the Device Twin (e.g. AppSKey).

Steps to Reproduce

1. Get the import template
2. Add an OTAA device without filling the ABP-specific columns
3. Import in the portal
4. Connect the device to your LoRa network

Context (Environment)

Portal version: 4.13.2
LoRaWAN Stack version: 2.2.2

Logs

Additional Information

[adcoly]

Removing those 3 parameters from the csv template does not fix the issue.
By the way, "TAG:supportLoRaFeatures" field is missing in the template.

[judramos]

If AppKey and AppEUI are filled, ABP properties (NwkSKey, AppSKey and DevAddr) are not setted in the device twin in azure.