- Fix invisible device while dragging from front to rear: the block
being dragged stayed structurally inside its own source <svg>, so it
rendered underneath the other panel once it visually overlapped it.
Replaced the in-SVG transform with a free-floating HTML ghost fixed
to <body> that tracks the pointer, unaffected by either SVG's own
stacking - the original block just dims in place during the drag, as
before.
- Fix rear elevation showing nothing for a device type with no
rear_image: only full-depth devices (which have a genuinely
different back) are restricted to their own rear image now; a
shallow device (e.g. a PDU) falls back to its front image on the
rear view, since that's usually the only picture that exists and is
still recognisable either way.
- Shorten the drag-hint badge text; the German translation of the
previous, longer wording didn't fit well next to the other controls
above the elevation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Front and rear panels already share one coordinate system (same
UNIT_HEIGHT, RACK_X, ...), just placed side by side on screen, so the
existing delta-based drag math is equally valid for a drop on the
other panel - only needed to detect which face the pointer ended up
over (elementFromPoint at drop time) and include it as `face` in the
submitted move; the reorder endpoint already supported changing it.
Also fixed a bug this surfaced: without pointer-events: none on the
dragged block during the drag, elementFromPoint() at drop time always
hit the dragged block itself (it's what's rendered under the cursor),
never the panel actually underneath - cross-face drops would never
have been detected. Pointer capture keeps delivering move/up events to
the block regardless of its own pointer-events value, so this is safe.
Added overflow: visible on the elevation SVGs so a device being
dragged toward the other panel doesn't just vanish at its own SVG's
edge mid-drag.
Updated the German translation for the changed drag-hint string.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
- Split the device detail page's single "Components" table into the
same seven tabs a real dcim.Device has, in the same order: Console
Ports, Console Server Ports, Power Ports, Power Outlets, Interfaces,
Front Ports, Rear Ports. Each tab is its own ObjectChildrenView
filtered by component_type (one ConceptComponent model backs all of
them, so this only needed the view/URL layer, not a schema change),
hidden when empty, exactly like core NetBox. Replace the ad hoc "Add
component" button with the same "Add Components" dropdown real
device pages use, one entry per type, each landing back on its own
tab.
- When copying a real rack into a concept (or merging two real racks
into one), automatically sync every copied device's components and
recreate, as ConceptCables, every real cable whose both ends land on
one of those devices - reading the same CableTermination data dcim
itself uses, so the copy comes out cabled internally the same as the
source. Cables reaching outside the copied rack(s), or multi-
termination trunk cables, are skipped and reported as a count in the
success message - the other end isn't part of the concept, so it
can't be represented. copy_rack_to_concept() and
merge_racks_to_concept() now return an extra cable_summary value;
updated all their callers (views and API).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PluginConfig._load_resource() prepends self.__module__ (already
'netbox_rack_concept') to the configured path, so 'menu' and
'template_extensions' must be given relative to the plugin package
('navigation.menu', 'template_content.template_extensions'), not
prefixed with 'netbox_rack_concept.' again. The prefixed form made
Django try to import 'netbox_rack_concept.netbox_rack_concept...',
which doesn't exist, crashing manage.py on every command.
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