starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Unexpected error when using non-alphanumeric characters in front port name range #5068

New Issue
Closed
opened 2025-12-29 19:23:46 +01:00 by adam · 10 comments
adam commented 2025-12-29 19:23:46 +01:00
Owner
Copy Link

Originally created by @sleepinggenius2 on GitHub (Jul 16, 2021).

NetBox version

v2.11.9

Python version

3.8

Steps to Reproduce

On a device with sufficient available rear ports:

  1. Click "Add front ports"
  2. In the "Name" enter "[1/1,2/2]"
  3. Select any "Type"
  4. Select two "Rear ports", like "COM:1" and "COM:2"
  5. Click "Create"

Expected Behavior

Two front ports "1/1" and "2/2" are created and linked to the selected rear ports.

Observed Behavior

The following error is seen under Rear ports:

  • The provided name pattern will create 1 ports, however 2 rear port assignments were selected. These counts must match.

I know the help text says that only alphanumeric ranges (-) are supported, but it is not intuitive that the same restriction should be applicable when a list (,) is provided.

When an invalid range is provided, like [1-A]/1, then you get a server error like:

<class 'KeyError'>

'name_pattern'

But entering [1,A]/1 creates ports "1/1" and "A/1", as expected. It seems inconsistent that the provided scenario should result in the current error and not one of these two outcomes.

Originally created by @sleepinggenius2 on GitHub (Jul 16, 2021). ### NetBox version v2.11.9 ### Python version 3.8 ### Steps to Reproduce On a device with sufficient available rear ports: 1. Click "Add front ports" 2. In the "Name" enter "[1/1,2/2]" 3. Select any "Type" 4. Select two "Rear ports", like "COM:1" and "COM:2" 5. Click "Create" ### Expected Behavior Two front ports "1/1" and "2/2" are created and linked to the selected rear ports. ### Observed Behavior The following error is seen under _Rear ports_: * The provided name pattern will create 1 ports, however 2 rear port assignments were selected. These counts must match. I know the help text says that only alphanumeric ranges (-) are supported, but it is not intuitive that the same restriction should be applicable when a list (,) is provided. When an invalid range is provided, like `[1-A]/1`, then you get a server error like: ``` <class 'KeyError'> 'name_pattern' ``` But entering `[1,A]/1` creates ports "1/1" and "A/1", as expected. It seems inconsistent that the provided scenario should result in the current error and not one of these two outcomes.
adam added the type: bugstatus: needs ownerpending closure labels 2025-12-29 19:23:46 +01:00
adam closed this issue 2025-12-29 19:23:46 +01:00
adam commented 2025-12-29 19:23:46 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 17, 2021):

There is a similar issue using the same syntax with "Label" ranges for Interfaces, Front Ports, and Rear Ports, but the error is as below:

  • The provided name pattern will create 2 components, however 1 labels will be generated. These counts must match.
@sleepinggenius2 commented on GitHub (Jul 17, 2021): There is a similar issue using the same syntax with "Label" ranges for _Interfaces_, _Front Ports_, and _Rear Ports_, but the error is as below: * The provided name pattern will create 2 components, however 1 labels will be generated. These counts must match.
adam commented 2025-12-29 19:23:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 19, 2021):

This is a great bug for someone new to the project to pick up. It should be limited to adjusting the ALPHANUMERIC_EXPANSION_PATTERN regular expression in utilities/forms/constants.py to match on certain non-alphanumeric characters.

@jeremystretch commented on GitHub (Jul 19, 2021): This is a great bug for someone new to the project to pick up. It should be limited to adjusting the `ALPHANUMERIC_EXPANSION_PATTERN` regular expression in [utilities/forms/constants.py](https://github.com/netbox-community/netbox/blob/develop/netbox/utilities/forms/constants.py) to match on certain non-alphanumeric characters.
adam commented 2025-12-29 19:23:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 30, 2021):

I think I have a fix for this, but are there any other characters that we should accommodate in addition to forward slashes?

@jeremystretch commented on GitHub (Jul 30, 2021): I think I have a fix for this, but are there any other characters that we should accommodate in addition to forward slashes?
adam commented 2025-12-29 19:23:47 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 30, 2021):

In my experience, I have seen the need for period (.) and colon (:) in the Name field. In addition to those, I have also seen plus (+), pound (#), at (@), and ampersand (&) in the Label field.

@sleepinggenius2 commented on GitHub (Jul 30, 2021): In my experience, I have seen the need for period (.) and colon (:) in the Name field. In addition to those, I have also seen plus (+), pound (#), at (@), and ampersand (&) in the Label field.
adam commented 2025-12-29 19:23:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 12, 2021):

After looking into this a bit further, I think it's a bit more involved to support the proposed behavior. We want to ensure we only match on alphanumeric characters when processing a range (e.g. [1-3]), but can accept other characters when dealing with a set (e.g. [1,2,3]).

Leaving this open for anyone else who would like to take a stab at it.

@jeremystretch commented on GitHub (Aug 12, 2021): After looking into this a bit further, I think it's a bit more involved to support the proposed behavior. We want to ensure we only match on alphanumeric characters when processing a range (e.g. `[1-3]`), but can accept other characters when dealing with a set (e.g. `[1,2,3]`). Leaving this open for anyone else who would like to take a stab at it.
adam commented 2025-12-29 19:23:48 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Aug 12, 2021):

I have a proof-of-concept, standalone class implementation (fully typed and tested), but looking through the NetBox code, there is some contention within utilities/forms/utils.py where the expand_ipaddress_pattern function uses the same parse_numeric_range function that expand_alphanumeric_pattern uses. It also looks like I don't currently account for hex ranges to properly support that use case, but can certainly add that. I also currently support ranges like [y-ab], which produces ['y', 'z', 'aa', 'ab'] and r[a,]a, which produces ['raa'], but I see in the test cases that those kind of ranges are supposed to error. Should that be an error or is that kind of output acceptable? In addition to arbitrary characters in comma-separated ranges, my current implementation also supports nested ranges, left space-padded ranges for alpha and numeric, and left zero-padded ranges for numeric. I would be happy to pass the code along for review or I'm open to suggestions on how to get it integrated into the codebase. Just a disclaimer, I'm not great at Python, so there are probably optimizations that could be made within my implementation. It's also currently recursive with a depth constraint, but I could certainly look at unrolling it if that's a concern.

@sleepinggenius2 commented on GitHub (Aug 12, 2021): I have a proof-of-concept, standalone class implementation (fully typed and tested), but looking through the NetBox code, there is some contention within **utilities/forms/utils.py** where the *expand_ipaddress_pattern* function uses the same *parse_numeric_range* function that *expand_alphanumeric_pattern* uses. It also looks like I don't currently account for hex ranges to properly support that use case, but can certainly add that. I also currently support ranges like `[y-ab]`, which produces `['y', 'z', 'aa', 'ab']` and `r[a,]a`, which produces `['raa']`, but I see in the test cases that those kind of ranges are supposed to error. Should that be an error or is that kind of output acceptable? In addition to arbitrary characters in comma-separated ranges, my current implementation also supports nested ranges, left space-padded ranges for alpha and numeric, and left zero-padded ranges for numeric. I would be happy to pass the code along for review or I'm open to suggestions on how to get it integrated into the codebase. Just a disclaimer, I'm not great at Python, so there are probably optimizations that could be made within my implementation. It's also currently recursive with a depth constraint, but I could certainly look at unrolling it if that's a concern.
adam commented 2025-12-29 19:23:48 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 12, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Oct 12, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:23:48 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Oct 14, 2021):

I'm still looking for some feedback on how to proceed with this.

@sleepinggenius2 commented on GitHub (Oct 14, 2021): I'm still looking for some feedback on how to proceed with this.
adam commented 2025-12-29 19:23:48 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 19, 2021):

@sleepinggenius2 Are you interested in working on this? As mentioned, all current test cases must be supported.,

@DanSheps commented on GitHub (Oct 19, 2021): @sleepinggenius2 Are you interested in working on this? As mentioned, all current test cases must be supported.,
adam commented 2025-12-29 19:23:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 18, 2021):

Closing this out as there have been no volunteers.

@jeremystretch commented on GitHub (Nov 18, 2021): Closing this out as there have been no volunteers.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: needs owner type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5068
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?