Closes #19499 - Add WirelessLink Bulk Import Support by Device and Interface Names

[pheus]

Fixes: #19499 - Wireless Link Bulk Import-Device/interface

• Enhances the WirelessLink bulk import form to support specifying site and device for both terminations (A and B), with dynamic queryset filtering based on selection. Also allows interfaces to be referenced by name (instead of ID) during import, improving usability for CSV workflows.
• Modifies the CSV data structure in WirelessLink test cases to include device names alongside interface names for both terminations.

[arthanson]

I created the device and interfaces and did the import correctly, that all worked fine. I removed the WirelessLink that was created and re-did the import but I changed device_a to a different device that didn't have the interface and imported and got the crash below.

May be an existing issue that was exposed by these changes but looks like some more validation might be needed.

  File "/Users/ahanson/dev/work/netbox/netbox/netbox/views/generic/bulk_views.py", line 505, in post
    new_objs = self.create_and_update_objects(form, request)
  File "/Users/ahanson/dev/work/netbox/netbox/netbox/views/generic/bulk_views.py", line 463, in create_and_update_objects
    if model_form.is_valid():
       ~~~~~~~~~~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.13/site-packages/django/forms/forms.py", line 206, in is_valid
    return self.is_bound and not self.errors
                                 ^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.13/site-packages/django/forms/forms.py", line 201, in errors
    self.full_clean()
    ~~~~~~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.13/site-packages/django/forms/forms.py", line 339, in full_clean
    self._post_clean()
    ~~~~~~~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox/netbox/netbox/forms/base.py", line 78, in _post_clean
    return super()._post_clean()
           ~~~~~~~~~~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.13/site-packages/django/forms/models.py", line 498, in _post_clean
    self.instance.full_clean(exclude=exclude, validate_unique=False)
    ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.13/site-packages/django/db/models/base.py", line 1654, in full_clean
    self.clean()
    ~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox/netbox/wireless/models.py", line 201, in clean
    if self.interface_a.type not in WIRELESS_IFACE_TYPES:
       ^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.13/site-packages/django/db/models/fields/related_descriptors.py", line 271, in __get__
    raise self.RelatedObjectDoesNotExist(
        "%s has no %s." % (self.field.model.__name__, self.field.name)
    )

[pheus]

Thanks for testing that out and for the detailed feedback!

You're absolutely right - that crash shouldn’t happen. The issue you encountered when device_a didn’t have the specified interface is definitely concerning.

I’ll take a closer look at the interface validation. Adding an explicit check to ensure the interface exists on the given device before attempting to create the WirelessLink would definitely improve robustness here.

Really appreciate you catching that!

[pheus]

I tracked down the root cause of the crash.

The issue stems from the model’s clean() method, which assumes that interface_a and interface_b are always set. However, during bulk import, it’s possible that one or both interfaces are missing (e.g., due to a typo or referencing a non-existent interface on the specified device). This causes an exception to be raised before the form validation can properly handle the error.

To resolve this, I’ve updated the clean() method to first check whether interface_a and interface_b are present before performing further validation. With this change, the crash no longer occurs, and the import form now correctly flags missing or invalid interfaces with a validation error instead of an unhandled exception.

Let me know if you'd prefer a different approach, but this seems like a safe and targeted fix that improves robustness.

[arthanson]

Thanks @pheus

[mblumber1]

Thank you!