Hierarchies and Tree View

Moltaro can present records that point to another record of the same type as a lazy, tabular hierarchy. The relationship remains ordinary record data; the Parent Tree View belongs to a configured Table Surface and determines how that data is read.

Supported in this version

• One optional direct, scalar self-Reference is the parent field.
• Any Table Surface, including the entity default, can own Tree View.
• Data Explorer, direct table hosts, Details/Drawer related tables, and full Reference Lookup pickers render it.
• Roots and each child sibling set are sorted and paged by the server.
• Search and filters retain visible ancestors needed to reach a match.
• Existing table columns, row actions, access checks, archive scope, and server-side sorting continue to apply.
• Multi-record selection and bulk actions remain desktop Data Explorer workflows. Narrow/mobile Data Explorer cards deliberately keep only row-level actions so the record surface stays compact. Crossing into mobile clears desktop selection and any pending group-action UI.

List and LongList reference controls remain flat-only because they do not host the complete lazy tree interaction. V1 has no drag-and-drop move, expand-all, subtree bulk operation, or write-time cycle prevention.

Parent hierarchy is not Group By

Parent Tree View follows a real Reference stored on each child:

Epic: Customer onboarding
├─ Request: Create account        ← Parent = Customer onboarding
│  └─ Request: Verify address     ← Parent = Create account
└─ Request: Send welcome pack     ← Parent = Customer onboarding

Group By would create transient headings from equal values such as Type, Status, or Owner. It does not follow parent records and is a separate future capability.

Core terms

Term	Meaning
Parent field	The configured direct self-Reference that stores a record’s parent.
Effective root	A visible record whose readable parent is absent from the current visible/archive scope.
Sibling set	Roots, or direct children of one parent, sorted and paged independently.
Ancestor context	A visible nonmatching record retained only to connect a matching descendant to a root.

Choose your path

• Using Tree View explains navigation, paging, sorting, filtering, desktop selection, export, and deliberate mobile limits.
• Configuring Parent Tree View covers the parent field, index, Table Surface, Entity List selector, and Lookup picker.
• Developer and API guide defines runtime contracts, routes, conflicts, and automation rules.
• Security, performance, and data integrity explains the visible forest, malformed links, index drift, and scale limits.

Invariants

The server, not the browser, owns hierarchy structure. A client never sends arbitrary edges. Direct table and picker clients send the parent record id, current query, and the Table Surface id/revision returned by bootstrap. A related Details/Drawer client instead sends the parent plus its layout item and opaque context revision; the server restores the hosted scope and configured sort. In both cases the server re-resolves the surface, applies record and field access, normalizes malformed finite cycles, and returns only visible rows and safe issue codes.

Unsupported assumptions

Do not infer that:

• selecting a node selects its descendants;
• root TotalCount is the total number of matching records;
• client-side sorting of an expanded flat projection is valid;
• making a Tree Table Surface default is isolated to that screen;
• List or LongList controls can silently flatten a Tree View;
• Parent Tree View changes the stored parent Reference or supplies hierarchy business rules.