Skip to content
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.

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

Show full Region hierarchy on all relevant object views #13735

Closed
sleepinggenius2 opened this issue Sep 11, 2023 · 0 comments · Fixed by #14213
Closed

Show full Region hierarchy on all relevant object views #13735

sleepinggenius2 opened this issue Sep 11, 2023 · 0 comments · Fixed by #14213
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application

Comments

@sleepinggenius2
Copy link
Contributor

NetBox version

v3.6.1

Feature type

Change to existing functionality

Proposed functionality

There seems to be some inconsistency with the way that the Region information is displayed in different object views. For a Device, there is a separate Region row shown in the UI with the full Region path. But, for Circuit Termination, Prefix, Rack, Rack Reservation, and VLAN (this is everything I could find with grep -F 'site.region|linkify', so maybe I missed something), only the leaf Region is shown on the Site row in the respective object view. My proposal would be to align the other models' object views to the way that Device does it, but I'm also fine with the regions staying on the Site line, as long as they show the full path, and ideally are consistent across all the object views.

I also noticed that models like Power Panels and Virtualization Clusters show the Site and no Region information. I'm not sure how to gather an exhaustive list for that scenario, but I feel like it should be consistent as well. Maybe there's a better way to DRY the site/location/rack and related site groups and regions into a separate template for consistency (understanding that location/rack may not be relevant to all models that support site)?

Use case

We are trying to implement a Region hierarchy that follows a pattern like State / City (which I think is fairly common) and it seems redundant to have to include the state as part of the city name, since the Region model only requires the name to be unique to its parent. There is also inconsistency today between how different models represent the same data in the UI, so that creates some visual dissonance. There are other areas of the UI that currently don't handle nested models very well, like table columns and dropdowns, but that's a separate issue.

Database changes

None

External dependencies

None

@sleepinggenius2 sleepinggenius2 added the type: feature Introduction of new functionality to the application label Sep 11, 2023
@jeremystretch jeremystretch added the status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation label Nov 6, 2023
@abhi1693 abhi1693 added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Nov 8, 2023
@abhi1693 abhi1693 self-assigned this Nov 8, 2023
abhi1693 added a commit that referenced this issue Nov 8, 2023
abhi1693 added a commit that referenced this issue Nov 8, 2023
abhi1693 added a commit that referenced this issue Nov 8, 2023
abhi1693 added a commit that referenced this issue Nov 9, 2023
abhi1693 added a commit that referenced this issue Nov 9, 2023
jeremystretch added a commit that referenced this issue Nov 29, 2023
* initial work to render hierarchical region #13735

* adds site display #13735

* cleanup #13735

* adds display region tag #13735

* refactored region hierarchy #13735

* refactored region hierarchy #13735

* renamed display_region to nested_tree #13735

* Make render_tree suitable for generic use

* Remove errant item from __all__

---------

Co-authored-by: Jeremy Stretch <jstretch@netboxlabs.com>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants