Copying one object

Sometimes you don’t want a venue. You want one WLAN — with its portal, its RADIUS profile, its DPSK pool, and everything else it quietly depends on — moved into another tenant.

That is element copy. It ships with the Copy feature, alongside venue copy, and reuses the same MOP engine, the same review-and-arm cycle, and the same undo.

What you can start from

Three element types:

type	The object
wlan	A WLAN (Wi-Fi network)
switchProfile	A switch profile, with its VLANs and ACLs
ethernetPortProfile	An AP ethernet-port (LAN-port) profile

The point is the closure, not the object. Extracting a WLAN pulls in the shared objects it binds — portal service profile, RADIUS server profiles, DPSK pool and its identity group, VLAN pool, Wi-Fi calling profile, access-control profile and its four child policies — because a WLAN recreated without them is not a working WLAN.

Call element_copy_support for the authoritative list of which domains an element copy carries. It is a filtered view of the venue-copy matrix: the tenant-scoped shared objects reachable downstream of an element, and nothing venue-scoped.

The pipeline

1. element_extract — identify the object by type plus either id (preferred, unambiguous) or name (matched exactly, and refused if more than one object shares it). Optionally connection to read from a non-default tenant. Like venue_extract it is chunked: if it comes back complete: false, call it again with the same snapshotId.

2. element_copy_plan — pass the completed snapshotId and targetConnection. It compiles an apply-MOP that creates the element and its whole closure in the target tenant and wires them to each other. It writes nothing. connection is accepted as an alias for targetConnection; passing both with different values is refused with ambiguous_target_connection, and an unknown key is an error rather than being ignored.

3. mop_replay { mopId, dryRun: true } — review every step.

4. mop_replay { mopId, armWrites: true } — run it. Arming names the target tenant first.

5. element_copy_verify { runId } — confirm it landed.

Reverse it with venue_copy_undo { runId }. No venue is deleted, because none was created.

Undo is available for about 7 days

venue_copy_undo and element_copy_verify { runId } both need the run’s record, and run records are swept 7 days after the run started. After that both return run_not_found, and the created objects have to be removed by hand.

Two things that surprise people

Same tenant needs a rename

Caution

A same-tenant element copy writes nothing and produces no MOP unless you rename it. The copy names every object exactly as the source does, so each one collides with itself and R1 refuses the duplicate name.

Pass rename to element_copy_plan to make it write:

rename	What gets created
{ name: "Guest-2" }	The element only, under the new name. Its shared services (DPSK pool, portal, RADIUS, VLAN pool, Wi-Fi calling, access-control profile and its policies) keep their names, are adopted, and the new element is bound to the very same objects.
{ prefix: "COPY-", scope: "closure" }	Every object the copy creates is renamed — a fully independent duplicate that shares nothing. The default scope is element, which renames only the element. suffix works the same way.
{ map: { "<source name>": "<new name>" } }	Specific objects, by exact source name. Wins over prefix/suffix.
{ ssid: "…" }	The WLAN’s broadcast SSID.

A renamed WLAN keeps the source SSID — renaming never moves the SSID on its own, so without ssid the copy broadcasts the same network name as the original (the plan warns). Anything ambiguous — a map key that matches nothing, a rename that yields the same name, two objects renamed onto one name — is refused rather than half-applied.

Cross-tenant copies need no rename. If you want the object on another venue in the same tenant rather than a second copy of it, that is a venue copy.

Nothing is activated

An element copy has no venue to activate on, so the element and its closure are created and fully wired — and then left unactivated. Activate them where you want them live afterwards.

This is the deliberate difference from a venue copy, which activates as it goes. It also means element copy carries no venue-scoped configuration at all: no AP radio, mesh, LED, or syslog settings, no AAA servers, no AP groups. Those belong to a venue.

Name collisions in the target

The second copy into a tenant you have copied into before is the normal case, and sharedCollision governs it — the same setting, the same three values, and the same default (adopt) as a venue copy. Matching is by name only; contents are never compared.

element_copy_plan has no collisionPolicy — that setting governs venue-scoped objects, and an element copy has none. Passing it is refused as an unknown argument. Use sharedCollision to decide what happens to a same-named object.

Note

adoptExisting still works and is superseded by sharedCollision, where adoptExisting: false means sharedCollision: "skip". Prefer sharedCollision — it is the only one that offers overwrite.

Verifying

After the copy has run, verify with runId — the plan returns it as verifyAfterRunWith. Every object the run created is re-read by the id the run captured, and its live name compared with the name the create sent; every bind is re-read from the bound profile’s /query row. It needs no other arguments. Objects the copy adopted are not checked, because the run never wrote them.

Before a run, pass snapshotId instead. That mode queries the target tenant for the exact name of every object the copy would create, and reports present or missing. Its checklist comes from the same plan the copy compiled, so pass the same sharedCollision, domains and rename the copy used (the plan returns them as verifyWith) — a different policy checks a different list than the copy created.

Caution

Don’t use snapshotId mode after the copy has run. The copy’s own objects are in the target by then, read as pre-existing, and are adopted off the checklist — so a successful copy reports checked: 0, complete: false. Use runId.

In snapshotId mode it separates three outcomes:

• Checked — objects the copy creates, name-verified in the target.
• adoptedObjects — objects that already existed and were adopted. These are never name-checked, because the name that would prove them present belongs to the pre-existing object.
• plannedSkips — objects the compiler deliberately dropped.

Note

Neither mode is a field-level re-diff. An element copy has no target venue to re-extract, so it cannot reach venue_copy_verify’s depth — and it says so in its own response.

Next steps

Venue config copy The whole-venue pipeline, and the collision policies element copy shares.

What a venue copy carries The full per-domain matrix that element_copy_support filters.

Venue backups Keeping a whole venue's configuration rather than moving one object.

Multiple connections Saving the target tenant an element copy writes to.