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

[PR #13730] [CLOSED] Second attempt at fixing #13722 and refactoring alphanumeric range code #14245

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

📋 Pull Request Information

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

Base: develop ← Head: 13722-alphanumeric-range-fixes-v2

📝 Commits (7)

📊 Changes

4 files changed (+66 additions, -55 deletions)

View changed files

📝 netbox/utilities/forms/constants.py (+5 -0)
📝 netbox/utilities/forms/fields/expandable.py (+1 -3)
📝 netbox/utilities/forms/utils.py (+22 -34)
📝 netbox/utilities/tests/test_forms.py (+38 -18)

📄 Description

Fixes: #13722

This pull request replaces my first train-wreck of an attempt in #13728.

The first two commits are preparatory refactoring work to improve the testability of current code.

First, I identified an issue where the tested behavious wasn't the actual behaviour. That's because expand_alphanumeric_pattern was only called from ExpandableNameField.to_python, which did its own regex matching on the input string before patting it over to expand_alphanumeric_pattern. It makes a lot more sense for that regex matching to only happen in expand_alphanumeric_pattern, so that was moved to that function, which, it turned out, was already doing it implicity by string splitting on the same regex.

Doing that change in turn made it possible to further simplify expand_alphanumeric_pattern by removing some unneccessary extra checks.

However, this caused some test failures. This is due to the fact that expand_alphanumeric_pattern's behaviour was changed. Before, it would throw an exception if there are no patterns in it, now it instead returns the string unmodified, which is exactly what the appication as a whole was doing, but now it's all contained in that function. That made it neccessary to adjust the unit tests to reflect this change of responsibility.

Once the prep-work was done, I replaced parse_alphanumeric_range with an almost entirely new implementation which I believe is cleaner and easier to read. This is what actually fixes the bug. It also adds some better error messages for the user when something goes wrong.

During the work in refactoring, I discovered another unrelated bug that also somehow made it into the test suite as a feature. For some reason, entering a string like r[a-9]a would make expand_alphanumeric_pattern return an empty list. This behaviour made no sense to me, so again, I changed the tests. This shouldn't have changed the external behaviour of the application, since when an empty list was received by to_python, the "name" field just ended up be empty, which in turn caused the form validation to fail with an incorrect message that the field was required. This way, there's a clearer error message as to what's going on.

There's still some improvements that could be done here, for example, I don't like how a pure utility function throws forms.ValidationError, but I'm not going to change it because it's not really causing any issues at the moment, and it's easy enough to change in the future if it ever becomes a concern.

🔄 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/13730 **Author:** [@pv2b](https://github.com/pv2b) **Created:** 9/9/2023 **Status:** ❌ Closed **Base:** `develop` ← **Head:** `13722-alphanumeric-range-fixes-v2` --- ### 📝 Commits (7) - [`d40a49e`](https://github.com/netbox-community/netbox/commit/d40a49e6e3f70ef13e792643c801accda4f9cb08) Refactor of expand_alphanumeric_pattern and tests - [`834d34a`](https://github.com/netbox-community/netbox/commit/834d34a01c7af78ba0bf034f1422edd25cc28045) Simplify expand_alphanumeric_pattern - [`a8c6f10`](https://github.com/netbox-community/netbox/commit/a8c6f10b06995c6f3c6d24640f6fc2148680d55a) Add test for #13722 - [`e485ed3`](https://github.com/netbox-community/netbox/commit/e485ed30c7ffad07276f1ea2189bf472a5f2cc7e) Rewrite parse_alphanumeric_range to fix #13722 - [`9f3c152`](https://github.com/netbox-community/netbox/commit/9f3c15201a156e4853770693fa976350ff808899) Fix bogus test_invalid_range_alphanumeric test - [`8bd37d3`](https://github.com/netbox-community/netbox/commit/8bd37d339e501c7ace06cc3317dc921e0f351150) Improve error message - [`218ac24`](https://github.com/netbox-community/netbox/commit/218ac240e6b6c05ef2785b925676acf573fbb142) Removed extra newline ### 📊 Changes **4 files changed** (+66 additions, -55 deletions) <details> <summary>View changed files</summary> 📝 `netbox/utilities/forms/constants.py` (+5 -0) 📝 `netbox/utilities/forms/fields/expandable.py` (+1 -3) 📝 `netbox/utilities/forms/utils.py` (+22 -34) 📝 `netbox/utilities/tests/test_forms.py` (+38 -18) </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. --> This pull request replaces my first train-wreck of an attempt in #13728. The first two commits are preparatory refactoring work to improve the testability of current code. First, I identified an issue where the tested behavious wasn't the actual behaviour. That's because `expand_alphanumeric_pattern` was only called from `ExpandableNameField.to_python`, which did its own regex matching on the input string before patting it over to `expand_alphanumeric_pattern`. It makes a lot more sense for that regex matching to only happen in `expand_alphanumeric_pattern`, so that was moved to that function, which, it turned out, was already doing it implicity by string splitting on the same regex. Doing that change in turn made it possible to further simplify `expand_alphanumeric_pattern` by removing some unneccessary extra checks. However, this caused some test failures. This is due to the fact that `expand_alphanumeric_pattern`'s behaviour was changed. Before, it would throw an exception if there are no patterns in it, now it instead returns the string unmodified, which is exactly what the appication as a whole was doing, but now it's all contained in that function. That made it neccessary to adjust the unit tests to reflect this change of responsibility. Once the prep-work was done, I replaced `parse_alphanumeric_range` with an almost entirely new implementation which I believe is cleaner and easier to read. This is what actually fixes the bug. It also adds some better error messages for the user when something goes wrong. During the work in refactoring, I discovered another unrelated bug that also somehow made it into the test suite as a feature. For some reason, entering a string like `r[a-9]a` would make `expand_alphanumeric_pattern` return an empty list. This behaviour made no sense to me, so again, I changed the tests. This shouldn't have changed the external behaviour of the application, since when an empty list was received by `to_python`, the "name" field just ended up be empty, which in turn caused the form validation to fail with an incorrect message that the field was required. This way, there's a clearer error message as to what's going on. There's still some improvements that could be done here, for example, I don't like how a pure utility function throws forms.ValidationError, but I'm not going to change it because it's not really causing any issues at the moment, and it's easy enough to change in the future if it ever becomes a concern. --- <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:23 +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#14245
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?