Skip to content

Inconsistent behaviour with Label on front port when using range #19230

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
LabelWriter450 opened this issue Apr 17, 2025 · 0 comments · Fixed by #19261
Closed

Inconsistent behaviour with Label on front port when using range #19230

LabelWriter450 opened this issue Apr 17, 2025 · 0 comments · Fixed by #19261
Assignees
@jeremystretch
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Milestone
v4.2.8

Comments

@LabelWriter450
Copy link

Deployment Type

Self-hosted

NetBox Version

v4.2.7

Python Version

3.10

Steps to Reproduce

  1. Go to Device
  2. Add "Add a new front Port"
  3. Select Device
  4. Give name [0-9]
  5. Give Label without range
  6. Assign Type
  7. Assign Rear Port

Expected Behavior

The front connections should be added with the same label

Observed Behavior

Error: "The provided pattern specifies 1 values, but 10 are expected."

It is not possible to add several front ports through range with the same label.
But it is possible to edit all of them at once afterwards and set the same label for all of them.

Image
Image

Follow up Issue of #19041
@LabelWriter450 LabelWriter450 added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Apr 17, 2025
@arthanson arthanson added severity: low Does not significantly disrupt application functionality, or a workaround is available status: backlog Awaiting selection for work and removed status: needs triage This issue is awaiting triage by a maintainer labels Apr 17, 2025
@jeremystretch jeremystretch self-assigned this Apr 22, 2025
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: backlog Awaiting selection for work labels Apr 22, 2025
@jeremystretch jeremystretch added this to the v4.2.8 milestone Apr 22, 2025
jeremystretch added a commit that referenced this issue Apr 22, 2025
@jeremystretch
Fixes #19230: Allow label reuse when creating multiple components fro…
b48101d 
…m a pattern
@jeremystretch jeremystretch mentioned this issue Apr 22, 2025
Merged
@jeremystretch jeremystretch mentioned this issue Apr 22, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jeremystretch jeremystretch

Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Milestone
v4.2.8
3 participants
@arthanson @jeremystretch @LabelWriter450