Member Junction
    Preparing search index...

    Interface FormPanelRegistrationMetadata

    Shape of the metadata object every BaseFormPanel registration MUST attach via @RegisterClass(BaseFormPanel, { metadata: {...} }). The <mj-form-panel-slot> host filters registrations by matching against this shape — registrations without it are silently ignored.

    • entity — the exact entity name (case-sensitive equality enforced by the slot host), OR the wildcard '*' to register an entity-agnostic panel that mounts on EVERY entity's form. Wildcard panels are expected to self-hide (render nothing) when they don't apply to the current record, so the cross-cutting registration stays unobtrusive on forms it has no business on.
    • slot — which slot the panel renders into.
    • sortKey— higher = earlier within the slot. Defaults to 0 if omitted. Use ranges (e.g., 100/50/10) so future panels can wedge in without recomputing every neighbor's sort.
    interface FormPanelRegistrationMetadata {
        chromeGroup?: "details" | "more";
        contributionKey?: string;
        entity: string;
        inclusion?: FormInclusion;
        leadsWhenUnsaved?: boolean;
        relatedEntity?: string;
        relatedJoinField?: string;
        replacesSectionKey?: string;
        slot: FormPanelSlot;
        sortKey?: number;
        [key: string]: unknown;
    }

    Hierarchy

    • Record<string, unknown>
      • FormPanelRegistrationMetadata

    Indexable

    • [key: string]: unknown
    Index

    Properties

    chromeGroup? contributionKey? entity inclusion? leadsWhenUnsaved? relatedEntity? relatedJoinField? replacesSectionKey? slot sortKey?

    Properties

    chromeGroup?: "details" | "more"

    Pin this contribution to a chrome bucket instead of its own rail item. 'details' — leftover own-fields group. 'more' — overflow folder.

    contributionKey?: string

    Identity for last-wins collapse. Two registrations with the same key compete; highest ClassFactory Priority wins. Omit to derive: related:${relatedEntity}:${relatedJoinField} when claiming a relationship, otherwise the registration is unique and never collapses.

    entity: string
    inclusion?: FormInclusion

    L1 inclusion for this contribution (same verbs as relationships). 'Primary' — own first-class rail item, in the lead band before Details. 'More' — overflow folder. 'None' — hidden. L3 MJ: Form Chrome Rules still wins. chromeGroup still merges.

    leadsWhenUnsaved?: boolean

    Open a NEW (unsaved) record on this contribution instead of the first first-class group.

    A saved record opens where the user last was, or on the lead group. That is right for reading a record and wrong for creating one: the lead group is usually a summary, and a summary of a record with no data is a page of blanks the user has to look past to find where typing starts.

    Only consulted when the record is unsaved, so it cannot change how an existing record opens. If several contributions on one entity set it, the highest ClassFactory Priority wins, matching how every other conflict between registrations is settled.

    relatedEntity?: string

    When set, this panel replaces the default related-entity grid for that relationship on entity's form. The baked CodeGen panel (if any) is hidden; the stock fill-in grid is not mounted.

    relatedJoinField?: string

    Disambiguates two FKs to the same related entity (BillTo vs ShipTo). Compared after stripping wrapping [].

    replacesSectionKey?: string

    CodeGen SectionKey of a baked field (or other) panel this contribution replaces — e.g. 'details', 'personalIdentity'. Hidden at runtime via HiddenSectionKeys. Use with slot: 'before-fields' for a form hero that is not a collapsible panel. Must name a concrete entity (not '*').

    slot: FormPanelSlot
    sortKey?: number

    Settings

    Member Visibility

    On This Page

    Properties