'WirelessLANImportForm' has no field named 'scope'.

[chucklesb]

Deployment Type

NetBox Cloud

NetBox Version

v4.3.3

Python Version

3.12

Steps to Reproduce

1. Navigate to Wireless > Wireless LANs
2. Click the "Import" button
3. Click the "Upload File" tab
4. Choose a CSV file and click the "Submit" button

Expected Behavior

The wireless LANs are imported into the database.

Observed Behavior

Server Error

There was a problem with your request. Please contact an administrator.

---

The complete exception is provided below:

<class 'ValueError'>

'WirelessLANImportForm' has no field named 'scope'.

Python version: 3.12.3
NetBox version: 4.3.3
Plugins: 
  nbc_auth_extensions: 1.19.1
  nbc_eventsink_extensions: 1.7.1
  nbc_requestmetric_extensions: 1.7.0
  netbox_branching: 0.6.0
  netbox_changes: 0.3.0
  netbox_labs_console: 1.7.2

[chucklesb]

I believe this error was caused by an invalid 'scope_id' value in my CSV. However, I think some improved input validation might be helpful. If I supply an invalid 'scope_id' when importing VLAN groups, I get a helpful error message: "Record 1 scope_id: Enter a whole number."

[arthanson]

@chucklesb can you please provide the csv values you were using and the corresponding extra data you need to create first (i.e. VLAN groups?) Please provide enough information and data so someone can reproduce the issue you are seeing.

[chucklesb]

Import a VLAN group with the following data:

name,slug,scope_type,scope_id
VLG0,vlg0,dcim.site,invalid

This results in a clear error message: Record 1 scope_id: Enter a whole number.

---

Import a Wireless LAN with the following data:

ssid,status,scope_type,scope_id
WLAN0,active,dcim.site,invalid

This results in a Python ValueError: 'WirelessLANImportForm' has no field named 'scope'.

[stuntguy3000]

@arthanson Can you please assign this to me, I'm currently investigating this one - bit of an interesting one involving the CachedScopeMixin!

[jnovinger]

Thanks @stuntguy3000 , assigning to you.

[stuntguy3000]

Here we go, down the rabbit hole 🐰

I've spent way too long on this, and whilst I have a working "fix", I'm not entirely sure if it's suitable, or a band-aid warranting deeper investigation. If a maintainer wants to make a call, I hope this scratch notes help guide you. I am by no means a Django expert, and this is outside of my wheelhouse.

With that out of the way, here's my understanding of the issue, which may not be 100% accurate.

---

The Background to CachedScopeMixin Cleaning/Validation

This CachedScopeMixin Validation (clean function) was introduced in December '24 #18203 0cda10a to resolve first and foremost, a user experience issue. This is a fairly "interesting" way to fix what is simply a form validation issue; It's unclear if this is, or is not, the best approach (as the change impacts much more than form submissions - such as in this instance).

This specific function already caused one bug (#19588) before, so this makes the second one, afaik.

To prevent a stack trace...

Modify the validation error to not specify "scope" field, which may or may not exist depending on the context (form submission, API call or model insertion/bulk creation).

I've tested this approach for form submissions and the bulk creation originally reported, and this "resolves" the stack trace.

forms.py/CachedScopeMixin

    def clean(self):
        if self.scope_type and not (self.scope or self.scope_id):
            scope_type = self.scope_type.model_class()

            raise ValidationError(_("Please select a {scope_type}.").format(scope_type=scope_type._meta.model_name)) # Edited line to resolve this issue
        [...]

However...

Based on my commentary above, I'm not sure if this is suitable - as this seems to be fixing the error, not the bug. I could be mistaken, but I'd seriously challenge if this function really is the best approach for fixing the ORIGINAL issues mentioned previously, as it's behavior changes based on the user's context/actions.

It's also not well documented and missing a clear code flow/understanding of what the heck it's doing!

---

Clarifying the scope of the issue (impacted models)

This issue pertains to Prefix, Cluster and WirelessLAN models, from my understanding. I've been able to replicate this issue on those object import forms, which do not contain a "Scope" field (which makes sense...)

Why don't other models (e.g. VLANGroup) have this issue?
I'm not sure.

Unlike the "impacted models", VLANGroup (as one example), does not inherit CachedScopeMixin - and does not undergo the same cleaning or validations, despite having identical Scope fields/features.

I cannot tell if this is an oversight, or intentional, and where I have to pass it on to those more in the know!

---

Thanks for coming to my Ted Talk.

Maintainers (@arthanson @jnovinger), I'm happy to submit my code above - but I'll let you decide on the next steps.