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

[PR #13728] [CLOSED] Rewrite of parse_alphanumeric_range and expand_alphanumeric_pattern #14241

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

📋 Pull Request Information

Original PR: https://github.com/netbox-community/netbox/pull/13728
Author: @pv2b
Created: 9/8/2023
Status: ❌ Closed

Base: develop ← Head: pv2b/13722-alphanumeric-range-fixes

📝 Commits (8)

  • 33d4a9a Add test for issue #13722
  • de8541c Fix tests for test_invalid_range_alphanumeric
  • 735d1ca Fixes #13722 by rewriting parse_alphanumeric_range and expand_alphanumeric_pattern
  • d762e7e Fix up some wonky code formatting
  • 49f53c5 Remove unused variable
  • e884e0c PEP8 fixes
  • 0da4940 Extract seperate function for preserving implementation warts in expand_alphanumeric_pattern, and simplify implementation
  • 1e6a800 Move translation of ValueError to ValidationError into to_python where it belongs

📊 Changes

4 files changed (+65 additions, -43 deletions)

View changed files

📝 netbox/utilities/forms/constants.py (+5 -0)
📝 netbox/utilities/forms/fields/expandable.py (+4 -1)
📝 netbox/utilities/forms/utils.py (+40 -38)
📝 netbox/utilities/tests/test_forms.py (+16 -4)

📄 Description

Fixes: #13722

The code for expand_alphanumeric_pattern and parse_alphanumeric_range which is used to expand range expressions such as Gi1/0/[1-24] had got a bit unruly and at least one bug had snuck in where a case like vlan[123,456] could not be parsed correctly. (Issue #13722).

The goal here was to add a unit test for that broken behaviour and then fix it. Fixing it turned into a complete rewrite/refactor of these two functions, because they had reached a point where they were no longer maintainable as is.

This refactor surfaced two other unexpected behaviours:

  1. When passing a pattern like r[a-9]a, which is invalid because it makes no sense to try to make a range from a letter to a number, the existing code returned an empty list. Surprisingly, the unit tests also seem to expect this very strange behaviour. Since the behaviour makes no sense, I didn't see any harm in changing the unit tests in order to reflect the new behaviour which is to throw an exception in thie case.

  2. There are some warts as to how exception handling works. The old code ended up throwing exceptions implicitly when failing to do number conversion, etc. Instead, I have opted to do explicit checking and exception thowing in all cases I've thought of. However, this surfaced another wart. It seems that depending on the exact nature of the error, sometimes the unit tests expect a forms.ValidationError and sometimes a ValueError. In my opinion the correct exception type is ValueError, the functions are generic utility functions and should not be coupled to django forms in any way. However, in an effort to remain bug-for-bug compatible with existing unit tests, I have added some code to expand_alphanumeric_pattern to catch and rethrow the exceptions using the "correct" exception type, thereby containing the wart to one place in the code. Fixing it would have to involve changing the unit tests and auditing all calling code, and that didn't really seem to be in the scope of this issue so I've left it be. Instead I've just added some comments for any future housekeeping.

Anyway, original bug seems to be squashed, so... mission accomplished?

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/netbox-community/netbox/pull/13728 **Author:** [@pv2b](https://github.com/pv2b) **Created:** 9/8/2023 **Status:** ❌ Closed **Base:** `develop` ← **Head:** `pv2b/13722-alphanumeric-range-fixes` --- ### 📝 Commits (8) - [`33d4a9a`](https://github.com/netbox-community/netbox/commit/33d4a9ab71a2d01a5ae1720885be24acac8f0cb7) Add test for issue #13722 - [`de8541c`](https://github.com/netbox-community/netbox/commit/de8541cccdd54f12853c0c1b142a298fb09ce65c) Fix tests for test_invalid_range_alphanumeric - [`735d1ca`](https://github.com/netbox-community/netbox/commit/735d1cacf4b17d8bf9c99ee7e790b920f0cbee39) Fixes #13722 by rewriting parse_alphanumeric_range and expand_alphanumeric_pattern - [`d762e7e`](https://github.com/netbox-community/netbox/commit/d762e7eedc61facfd5d4d572b76f2b68dee711a1) Fix up some wonky code formatting - [`49f53c5`](https://github.com/netbox-community/netbox/commit/49f53c54d77871689199e5b3e9f19009b12c0eda) Remove unused variable - [`e884e0c`](https://github.com/netbox-community/netbox/commit/e884e0cbf9b80884b26ecd21bd6f1702ba6a1f8d) PEP8 fixes - [`0da4940`](https://github.com/netbox-community/netbox/commit/0da4940fe401e77133ea01dbd87e3223aea35eb7) Extract seperate function for preserving implementation warts in expand_alphanumeric_pattern, and simplify implementation - [`1e6a800`](https://github.com/netbox-community/netbox/commit/1e6a800959cb5a3ba5c528ec7fbbcfa3e6843d8f) Move translation of ValueError to ValidationError into to_python where it belongs ### 📊 Changes **4 files changed** (+65 additions, -43 deletions) <details> <summary>View changed files</summary> 📝 `netbox/utilities/forms/constants.py` (+5 -0) 📝 `netbox/utilities/forms/fields/expandable.py` (+4 -1) 📝 `netbox/utilities/forms/utils.py` (+40 -38) 📝 `netbox/utilities/tests/test_forms.py` (+16 -4) </details> ### 📄 Description <!-- Thank you for your interest in contributing to NetBox! Please note that our contribution policy requires that a feature request or bug report be approved and assigned prior to opening a pull request. This helps avoid waste time and effort on a proposed change that we might not be able to accept. IF YOUR PULL REQUEST DOES NOT REFERENCE AN ISSUE WHICH HAS BEEN ASSIGNED TO YOU, IT WILL BE CLOSED AUTOMATICALLY. Please specify your assigned issue number on the line below. --> ### Fixes: #13722 <!-- Please include a summary of the proposed changes below. --> The code for `expand_alphanumeric_pattern` and `parse_alphanumeric_range` which is used to expand range expressions such as `Gi1/0/[1-24]` had got a bit unruly and at least one bug had snuck in where a case like `vlan[123,456]` could not be parsed correctly. (Issue #13722). The goal here was to add a unit test for that broken behaviour and then fix it. Fixing it turned into a complete rewrite/refactor of these two functions, because they had reached a point where they were no longer maintainable as is. This refactor surfaced two other unexpected behaviours: 1. When passing a pattern like `r[a-9]a`, which is invalid because it makes no sense to try to make a range from a letter to a number, the existing code returned an empty list. Surprisingly, the unit tests also seem to expect this very strange behaviour. Since the behaviour makes no sense, I didn't see any harm in changing the unit tests in order to reflect the new behaviour which is to throw an exception in thie case. 2. There are some warts as to how exception handling works. The old code ended up throwing exceptions implicitly when failing to do number conversion, etc. Instead, I have opted to do explicit checking and exception thowing in all cases I've thought of. However, this surfaced another wart. It seems that depending on the exact nature of the error, sometimes the unit tests expect a `forms.ValidationError` and sometimes a `ValueError`. In my opinion the correct exception type is `ValueError`, the functions are generic utility functions and should not be coupled to django forms in any way. However, in an effort to remain bug-for-bug compatible with existing unit tests, I have added some code to `expand_alphanumeric_pattern` to catch and rethrow the exceptions using the "correct" exception type, thereby containing the wart to one place in the code. Fixing it would have to involve changing the unit tests and auditing all calling code, and that didn't really seem to be in the scope of this issue so I've left it be. Instead I've just added some comments for any future housekeeping. Anyway, original bug seems to be squashed, so... mission accomplished? --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2025-12-29 23:23:22 +01:00
adam closed this issue 2025-12-29 23:23:23 +01:00
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 pull-request
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#14241
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?