Investigated how MrBlake/mrb-netbox-topology-views does its PNG export:
it renders its topology natively onto a canvas (vis-network draws
there directly) and just calls canvas.toDataURL() - no SVG round-trip
at all. Applied the same principle here.
Previous approach loaded the standalone SVG export via <img src="blob:...">
and rasterized that onto a canvas - fragile, because the whole export
failed if that SVG document wasn't strictly valid XML (as our leaked
{# #} comment bug demonstrated) or if a single device type image
reference inside it couldn't be resolved.
New approach: a dedicated export/data/ endpoint returns the elevation's
plain pixel geometry as JSON (positions, sizes, colors, labels, image
URLs - the same numbers the SVG is built from), and export.js draws
that directly onto a <canvas> with native 2D primitives (fillRect,
strokeRect, fillText/strokeText, drawImage). Device type images are
fetched individually as same-origin blobs before drawing; one image
failing to load only drops that picture; the rest of the export still
succeeds. Added a combined front+rear PNG option.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Fix template comments rendering as literal text: Django's {# #} tag
regex (tag_re in django/template/base.py) has no re.DOTALL, so a
comment spanning multiple lines is never recognized as a tag at all
and leaks into the rendered output verbatim - exactly what showed up
under "Elevation". Collapsed all three offending comments to single
lines. This was also almost certainly the real cause of the "PNG
could not be generated" report: two of the leaked comments sat
inside the shared SVG partial, corrupting the exported SVG enough
that the browser's image decoder rejected it (my own onerror handler
then showed a misleading CORS-sounding message - the actual bug was
malformed markup, not cross-origin images).
- Add a German translation (locale/de/), built from every _() and
{% trans %}/{% blocktrans %} string in the plugin (269 entries,
cross-checked against the source for completeness). English needs no
catalog of its own since it's the literal source text; both were
already listed in NetBox's own language selector.
- Add CHANGELOG.md and bump the version to 0.2.0, covering this and
every unreleased change so far; will keep bumping per change from
here on.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Introduces a NetBox 4.6 plugin for planning rack layouts (RackConcept,
ConceptDevice) without creating real dcim.Rack/dcim.Device objects, so
blueprints never appear in rack/device lists, utilization reports, or
IPAM.
Features:
- Copy paths: real rack -> concept, concept -> concept (clone), and
concept -> one or more real racks (deploy, with name patterning and
dry-run support)
- Manual concept creation via a dedicated "Rack Concepts" nav menu
- Tenant and tenant group assignment on concepts and planned devices
- Partial-width device placement (1/1-1/4) with slot-based collision
detection, matching netbox_utilities' partial-width feature
- Custom drag-and-drop elevation (netbox-reorder-rack operates on real
Device querysets, which concepts don't have) with server-side
validation of every move
- Full REST API, filtering, CSV import, bulk edit, search integration
- Optional, config-driven interop with netbox_utilities (partial-width
field mapping) and netbox-reorder-rack, degrading gracefully when
either plugin is absent
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MrBlakeandClaude Sonnet 5