Fix single {module} token rejection at nested module bay depth #93

Closed
opened 2026-04-05 16:21:36 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @mrmrcoleman on 3/24/2026

Fixes: #20474

Summary

Fixes a bug where installing a module type with a single {module} placeholder into a nested module bay (depth > 1) was rejected with: "Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given."

  • A single {module} token now resolves to the immediate parent bay's position regardless of nesting depth
  • Multi-token {module} behavior is unchanged (token count must still match tree depth)
  • Refactors resolve_name() and resolve_label() into a shared _resolve_module_placeholder() helper to eliminate duplication

Changes

File Change
dcim/forms/common.py Single {module} token resolves to parent bay position instead of erroring; multi-token validation unchanged
dcim/models/device_component_templates.py Consolidated resolve_name()/resolve_label() into shared _resolve_module_placeholder() with same single-token logic
dcim/tests/test_models.py Regression test: single {module} SFP module installs at depth 2 and resolves to parent position

Testing

All existing dcim model and form tests pass (59 tests). Added one regression test that reproduces the exact scenario from #20474:

  1. Create a chassis with a rear card slot (depth 1)
  2. Install a rear card module with SFP slots (depth 2)
  3. Install an SFP module type with SFP {module} interface template into depth 2
  4. Verify the interface resolves to SFP 2 (parent bay position) instead of raising a ValidationError
*Originally created by @mrmrcoleman on 3/24/2026* ### Fixes: #20474 ## Summary Fixes a bug where installing a module type with a single `{module}` placeholder into a nested module bay (depth > 1) was rejected with: *"Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given."* - A single `{module}` token now resolves to the immediate parent bay's position regardless of nesting depth - Multi-token `{module}` behavior is unchanged (token count must still match tree depth) - Refactors `resolve_name()` and `resolve_label()` into a shared `_resolve_module_placeholder()` helper to eliminate duplication ## Changes | File | Change | |------|--------| | `dcim/forms/common.py` | Single `{module}` token resolves to parent bay position instead of erroring; multi-token validation unchanged | | `dcim/models/device_component_templates.py` | Consolidated `resolve_name()`/`resolve_label()` into shared `_resolve_module_placeholder()` with same single-token logic | | `dcim/tests/test_models.py` | Regression test: single `{module}` SFP module installs at depth 2 and resolves to parent position | ## Testing All existing dcim model and form tests pass (59 tests). Added one regression test that reproduces the exact scenario from #20474: 1. Create a chassis with a rear card slot (depth 1) 2. Install a rear card module with SFP slots (depth 2) 3. Install an SFP module type with `SFP {module}` interface template into depth 2 4. Verify the interface resolves to `SFP 2` (parent bay position) instead of raising a `ValidationError`
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/netbox#93