Mindmap ordering anchors and layout
move_node has no public index, position, or sortKey input. Place a node with sibling anchors under newParentId: beforeNodeId means immediately after that sibling, and afterNodeId means immediately before that sibling. If both are supplied, those siblings must be adjacent. An anchor outside the target parent’s active children conflicts. Omitting both appends the node to that sibling band. Roots share the null-parent sibling band, so independent-root creation or detach appends there unless anchors are supplied.
sortKey is a server-managed, 20-character zero-padded numeric string. When ranks are tight, the server rebalances; response siblingSortKeys are authoritative. get_mindmap orders nodes by parent, sortKey, then creation time.
Each tree is independent. A root’s canvas anchor is its manualOffset; non-root offsets are relative. layoutSide is auto, left, or right only for the direct children of that tree’s root. add_node and create-node APIs accept both layout fields. A deeper create carrying layoutSide is invalid. manualOffset components must be between -100,000 and 100,000; null clears it. Detach requires the child’s absolute offset and clears its side; attach sends null. Promote-delete Actions cannot supply child anchors, so root children use fallback anchors; only v1 REST accepts them.
Reparenting uses a per-Mindmap server lock. On conflict, reread the current forest and anchors before retrying.
Related actions
Section titled “Related actions”arinova.mindmap.get_mindmap, arinova.mindmap.add_node, arinova.mindmap.update_node, arinova.mindmap.move_node, arinova.mindmap.delete_node_promote_children
Also known as
reorder mindmap nodes, sibling anchors, layout side, manual offset, sort key
Build a7f47a5ca54ddcf7806cd48b81ce1b9827042766