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 #3702] [MERGED] Rack elevations API #12619

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

📋 Pull Request Information

Original PR: https://github.com/netbox-community/netbox/pull/3702
Author: @hellerve
Created: 11/21/2019
Status: ✅ Merged
Merged: 12/9/2019
Merged by: @lampwins

Base: 2248-svg-rack-elevations ← Head: rack-elevations-api

📝 Commits (10+)

  • d11de6d dcim: add rack-elevations api endpoint (references #2248)
  • 808f5c9 dcim: make front and rear work (references #2248)
  • 1a9b9f5 dcim: fix fonts & texts in svg
  • 77890ad dcim: add inline stylesheet to rack elevation api view
  • 5d5b7e0 dcim: refactor reservations and make them resizable
  • e1fdc77 requirements: fix svgwrite version
  • bc859c6 css: purge outdated rack styling
  • 82819d5 dcim: remove elevation getters
  • 66b6f58 tests: update to reflect absence of utility functions
  • b54a05d dcim: make linter happy

📊 Changes

12 files changed (+202 additions, -259 deletions)

View changed files

📝 netbox/dcim/api/serializers.py (+1 -1)
📝 netbox/dcim/api/urls.py (+1 -0)
📝 netbox/dcim/api/views.py (+134 -5)
📝 netbox/dcim/constants.py (+55 -0)
📝 netbox/dcim/models.py (+3 -15)
📝 netbox/dcim/tests/test_models.py (+2 -2)
📝 netbox/dcim/views.py (+0 -2)
📝 netbox/project-static/css/base.css (+0 -188)
📝 netbox/templates/dcim/inc/rack_elevation.html (+1 -42)
📝 netbox/templates/dcim/rack.html (+2 -2)
📝 netbox/templates/dcim/rack_elevation_list.html (+2 -2)
📝 requirements.txt (+1 -0)

📄 Description

Fixes: #2248

This PR introduces the rack elevations API. It’s a bit special because it returns SVG results. It replaces the current inline div-based solution. I marked it as a draft because there are a few open questions.

I guess an overview of what its capabilities are are in order. Basically, you call /api/dcim/rack-elevations/<rack-pk>, and you get back a SVG of that rack’s elevations. There are three URL parameters here:

  • face: specifies which face to render, 0 for front, 1 for rear. Front is the default.
  • width: specifies the desired width of the SVG in pixels. 230 is the default.
  • slot_height: specifies the height of one slot (i.e. one rack unit). I opted for this rather than a total height because the height of racks is usually not as important visually as the height of the devices/components. (I’m not sure about the naming of this param and/or you’d rather like to have total height. Input is appreciated)

The look and feel of the rendered SVG is pretty much identical to that of the DIV, save any bugs or open questions.

Open Questions

The big one first: what about those tooltips? They’re super useful and I kind of don’t want to lose them, but they’re really not meant to be ported to SVGs. If you twist my arm I can port them, but if we can find a better solution that’d be great!

Then there are a few open questions related to the code climate:

  • For the foreground color I’m currently reusing the fgcolor utility,w hich is a templatetag. That’s kind of bad style, and I’d opt for extracting that functionality into a helper that is shared by the tempalte tag and the elevation API if desired (it’s desired by me, anyway).
  • The stylesheet that we’re using for the rendered SVG is inline, which I think is good (so that the SVG is freestanding). But it’s also inline in the sense of within the source code, which is... less ideal. Where should we put it?
  • The viewset is fairly readable (to me anyway), but I’m sure it could be improved. Any feedback here is appreciated. A few things that I’m not sure of myself:
    • The GET param validation happens fairly manually. It’s alright I guess, but maybe REST framework has something fancy that we could use?
    • While most of the functions are local to the view set, they are generic helpers that don’t use self at all. Should they be factored out somewhere?
    • I’m getting the elevations myself instead of using rack.get_*_elevation because I always need both anyway and I was able to simplify the code tremendously by specializing it. At first I tried to reuse the functions, but this leads to more queries and a bunch of glue code to fuse everything. In fact, I was able to remove the rack.get_*_elevation functions alltogether, and the remove_redundant keyword argument, since they’re now unused. Is the handful of lines of kind-of-but-not-really duplicated code acceptable if we get rid of basically the same amount of code in return?
    • I was liberal in removing legacy code, including stylesheets only used by the elevations and such, and I’m pretty sure nothing broke, but you never know. Is there anything I missed?

All in all, this was equally fun and frustrating, and I hope this is either already useful or can be made useful. I’m looking forward to your review!

Cheers

🔄 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/3702 **Author:** [@hellerve](https://github.com/hellerve) **Created:** 11/21/2019 **Status:** ✅ Merged **Merged:** 12/9/2019 **Merged by:** [@lampwins](https://github.com/lampwins) **Base:** `2248-svg-rack-elevations` ← **Head:** `rack-elevations-api` --- ### 📝 Commits (10+) - [`d11de6d`](https://github.com/netbox-community/netbox/commit/d11de6d021624208e3e913f220cc8c8404c43ac6) dcim: add rack-elevations api endpoint (references #2248) - [`808f5c9`](https://github.com/netbox-community/netbox/commit/808f5c95e390923e834a3b3d1d791576dc6ed10a) dcim: make front and rear work (references #2248) - [`1a9b9f5`](https://github.com/netbox-community/netbox/commit/1a9b9f50d823bbb58ad800a9bbd6d1c999a211bd) dcim: fix fonts & texts in svg - [`77890ad`](https://github.com/netbox-community/netbox/commit/77890ad77558b426d457b5230702f99519fba356) dcim: add inline stylesheet to rack elevation api view - [`5d5b7e0`](https://github.com/netbox-community/netbox/commit/5d5b7e0dd92c01276c611990f87d0778cc48029a) dcim: refactor reservations and make them resizable - [`e1fdc77`](https://github.com/netbox-community/netbox/commit/e1fdc7773a921d9dfd9e15ad6890baaf609eb4f1) requirements: fix svgwrite version - [`bc859c6`](https://github.com/netbox-community/netbox/commit/bc859c6139e15aa96313edc0c763ae89d2231bb0) css: purge outdated rack styling - [`82819d5`](https://github.com/netbox-community/netbox/commit/82819d54290a240e63fc7137f37a12a7a635b54e) dcim: remove elevation getters - [`66b6f58`](https://github.com/netbox-community/netbox/commit/66b6f586f1639020a8168424d9215344d59a2fb0) tests: update to reflect absence of utility functions - [`b54a05d`](https://github.com/netbox-community/netbox/commit/b54a05d2558b05b349b8144dfca93f0f48509420) dcim: make linter happy ### 📊 Changes **12 files changed** (+202 additions, -259 deletions) <details> <summary>View changed files</summary> 📝 `netbox/dcim/api/serializers.py` (+1 -1) 📝 `netbox/dcim/api/urls.py` (+1 -0) 📝 `netbox/dcim/api/views.py` (+134 -5) 📝 `netbox/dcim/constants.py` (+55 -0) 📝 `netbox/dcim/models.py` (+3 -15) 📝 `netbox/dcim/tests/test_models.py` (+2 -2) 📝 `netbox/dcim/views.py` (+0 -2) 📝 `netbox/project-static/css/base.css` (+0 -188) 📝 `netbox/templates/dcim/inc/rack_elevation.html` (+1 -42) 📝 `netbox/templates/dcim/rack.html` (+2 -2) 📝 `netbox/templates/dcim/rack_elevation_list.html` (+2 -2) 📝 `requirements.txt` (+1 -0) </details> ### 📄 Description ### Fixes: #2248 This PR introduces the rack elevations API. It’s a bit special because it returns SVG results. It replaces the current inline `div`-based solution. I marked it as a draft because there are a few open questions. I guess an overview of what its capabilities are are in order. Basically, you call `/api/dcim/rack-elevations/<rack-pk>`, and you get back a SVG of that rack’s elevations. There are three URL parameters here: - `face`: specifies which face to render, `0` for front, `1` for rear. Front is the default. - `width`: specifies the desired width of the SVG in pixels. 230 is the default. - `slot_height`: specifies the height of one slot (i.e. one rack unit). I opted for this rather than a total height because the height of racks is usually not as important visually as the height of the devices/components. (I’m not sure about the naming of this param and/or you’d rather like to have total height. Input is appreciated) The look and feel of the rendered SVG is pretty much identical to that of the DIV, save any bugs or open questions. ### Open Questions The big one first: what about those tooltips? They’re super useful and I kind of don’t want to lose them, but they’re really not meant to be ported to SVGs. If you twist my arm I can port them, but if we can find a better solution that’d be great! Then there are a few open questions related to the code climate: - For the foreground color I’m currently reusing the `fgcolor` utility,w hich is a templatetag. That’s kind of bad style, and I’d opt for extracting that functionality into a helper that is shared by the tempalte tag and the elevation API if desired (it’s desired by me, anyway). - The stylesheet that we’re using for the rendered SVG is inline, which I think is good (so that the SVG is freestanding). But it’s also inline in the sense of `within the source code`, which is... less ideal. Where should we put it? - The viewset is fairly readable (to me anyway), but I’m sure it could be improved. Any feedback here is appreciated. A few things that I’m not sure of myself: - The GET param validation happens fairly manually. It’s alright I guess, but maybe REST framework has something fancy that we could use? - While most of the functions are local to the view set, they are generic helpers that don’t use `self` at all. Should they be factored out somewhere? - I’m getting the elevations myself instead of using `rack.get_*_elevation` because I always need both anyway and I was able to simplify the code tremendously by specializing it. At first I tried to reuse the functions, but this leads to more queries and a bunch of glue code to fuse everything. In fact, I was able to remove the `rack.get_*_elevation` functions alltogether, and the `remove_redundant` keyword argument, since they’re now unused. Is the handful of lines of kind-of-but-not-really duplicated code acceptable if we get rid of basically the same amount of code in return? - I was liberal in removing legacy code, including stylesheets only used by the elevations and such, and I’m pretty sure nothing broke, but you never know. Is there anything I missed? All in all, this was equally fun and frustrating, and I hope this is either already useful or can be made useful. I’m looking forward to your review! Cheers --- <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 22:22:40 +01:00
adam closed this issue 2025-12-29 22:22:41 +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#12619
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?