Fixes #21711: Added support for filtering and viewing modules by their module type profile

[ITJamie]

Fixes: #21711

Added support for filtering /dcim/modules/ by module type profile, matching the existing module type profile relationship on ModuleType.

Changes

• Added profile and profile_id filters to the module list filterset.
• Exposed module profile filtering in the module list UI, including support for None / unprofiled module types.
• Added module profile as an available table field in /dcim/modules/.
• Added REST API test coverage for filtering modules by profile ID and profile name.
• Added UI filterset, form, table, and utility widget regression tests.
• Updated the module model documentation to describe profile-based filtering.
• Updated Module Panel to display Module Profile

[pheus]

@claude /review Only report on issues of potential concern; we don't need commentary on anything that doesn't require further consideration.

[claude]

Claude finished @pheus's task in 2m 13s —— View job

---

Code Review

• Read changed files
• Analyze for issues of concern
• Post review findings

---

Two items worth flagging:

1. FilterModifierWidget change has broader scope than described

netbox/utilities/forms/widgets/modifiers.py:133-141 introduces a behavior change that affects all filter forms with null_option-configured fields — not just the new module profile filter. There are ~14 such fields across dcim/forms/filtersets.py alone.

The fix is logically correct: FilterModifierWidget.get_context() was previously clearing choices to [] when nothing was selected, which silently dropped the null option that DynamicModelMultipleChoiceField.get_bound_field() had just prepended (line 167-171 in dynamic.py). The new code preserves it via data-null-option.

However, the PR description only mentions this change indirectly ("utility widget regression tests"). Given the broad impact, it would be worth explicitly calling this out as a pre-existing bug fix, and confirming no regressions appear in the UI for other fields that currently have null_option (e.g. rack_id, tenant_id, owner_id fields across DCIM forms).

2. Hardcoded "null" string in test

netbox/dcim/tests/test_forms.py:186:

self.assertIn('value="null"', html)

This hardcodes the value of settings.FILTERS_NULL_CHOICE_VALUE. While that setting is currently 'null' and unlikely to change, using settings.FILTERS_NULL_CHOICE_VALUE would be consistent with how the same assertion is written elsewhere (e.g. test_filter_modifiers.py:131). Minor, but worth noting.

[ITJamie]

Re 1

This was a pain point when I was testing locally. I can drop it if its too far out of scope.

Re 2

Is the preference to lookup the settings reference or to use the hardcoded string

[arthanson]

Looks good, a few changes:

1. Please take out the null option widget change - if desired open up a separate FR and PR for that as it is outside the scope of this issue.
2. Use settings.FILTERS_NULL_CHOICE_VALUE in tests rather than the literal string. see test_filter_modifiers.py:110,131 - null_value = settings.FILTERS_NULL_CHOICE_VALUE, and test_filters.py:81,89 - same pattern
3. I think it makes potentially makes sense to add this to the detail view as well, under Module Type. As we are filtering on it and in the table seems like it should probably be in the detail view for the module?

[ITJamie]

Changes made as requested

[arthanson]

Thanks @ITJamie

[jeremystretch]

This should not have been added. There is no profile field on the Module model.