@masterteam/client-components 0.0.95 → 0.0.97

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@masterteam/client-components",
-  "version": "0.0.95",
+  "version": "0.0.97",
   "publishConfig": {
     "directory": "../../../dist/masterteam/client-components",
     "linkDirectory": true,
@@ -16,10 +16,10 @@
     "rxjs": "^7.8.2",
     "tailwindcss": "^4.2.2",
     "tailwindcss-primeui": "^0.6.1",
-    "@masterteam/forms": "^0.0.155",
-    "@masterteam/components": "^0.0.300",
-    "@masterteam/dashboard-builder": "^0.0.92",
-    "@masterteam/icons": "^0.0.17"
+    "@masterteam/forms": "^0.0.157",
+    "@masterteam/icons": "^0.0.17",
+    "@masterteam/components": "^0.0.302",
+    "@masterteam/dashboard-builder": "^0.0.92"
   },
   "dependencies": {
     "tslib": "^2.8.1"

package/types/masterteam-client-components-client-instance-preview.d.ts

@@ -1,7 +1,7 @@
 import * as _angular_core from '@angular/core';
 import { OnDestroy } from '@angular/core';
 import * as _masterteam_components_entities from '@masterteam/components/entities';
-import { EntityData, EntityViewType, EntityListPreviewContext } from '@masterteam/components/entities';
+import { EntityRuntimeContext, EntityData, EntityViewType } from '@masterteam/components/entities';
 import { Observable } from 'rxjs';
 
 interface ClientInstancePreviewConfig {
@@ -9,6 +9,17 @@ interface ClientInstancePreviewConfig {
     instanceId: number;
     displayAreas?: string[];
     processRequestId?: number;
+    /**
+     * Owning level and level-data ids, for the renderers that fetch data of
+     * their own — today a module-backed `EntityList`, which renders as the real
+     * related-records table when this is present and as a count-and-drawer
+     * trigger when it is not.
+     *
+     * It has to come from the host. The response's own `context` carries the
+     * level id, but its `scopeId` is the *level-module* id, not the level-data
+     * row, and nothing else in the payload identifies that row.
+     */
+    runtimeContext?: EntityRuntimeContext;
     /**
      * Optional host projection applied after the preview response is converted
      * to renderable entities. Use it to merge or derive presentation-only
@@ -75,8 +86,22 @@ interface PreviewFetchCatalog {
      */
     nestedProperties?: Record<string, PreviewFetchPropertyMeta[]>;
 }
+/**
+ * The resolved context of the fetched record. `scopeId` is the level-module
+ * id (`FetchContext.Scope.CompositeId`), **not** the level-data row — a host
+ * that needs that one supplies it through `runtimeContext`.
+ */
+interface PreviewFetchContext {
+    kind?: string;
+    levelId?: number;
+    moduleId?: number;
+    templateId?: number;
+    scopeId?: number;
+    hasWorkSpace?: boolean;
+}
 interface PreviewFetchRecordResponse {
     contextKey: string;
+    context?: PreviewFetchContext | null;
     schemas?: PreviewFetchSchema[];
     catalog?: PreviewFetchCatalog;
     record?: PreviewFetchRecord | null;
@@ -94,6 +119,7 @@ interface DisplayConfiguration {
 }
 interface PreviewResponse {
     contextKey: string;
+    context: PreviewFetchContext | null;
     schemas: PreviewFetchSchema[];
     catalog: PreviewFetchCatalog;
     record: PreviewFetchRecord | null;
@@ -103,6 +129,7 @@ interface PreviewResponse {
 declare class ClientInstancePreview implements OnDestroy {
     private readonly clientInstancePreviewApiService;
     private readonly transloco;
+    private readonly runtimeContextStore;
     private loadSub?;
     readonly config: _angular_core.InputSignal<ClientInstancePreviewConfig>;
     /** When true, suppresses the "No preview data" empty-state placeholder so the host can collapse. */
@@ -114,28 +141,9 @@ declare class ClientInstancePreview implements OnDestroy {
      * honored instead. The hard ≤280px overflow stack always applies regardless.
      */
     readonly stackOnNarrow: _angular_core.InputSignal<boolean>;
-    /**
-     * Level-data row the previewed record belongs to.
-     *
-     * Supplying it renders every `EntityList` property as the full read-only
-     * table the form shows, instead of a count and a drawer. That table loads
-     * itself from `Properties/{propertyId}/entitylist/table-metadata` and
-     * `fetch/query`, which need the owning level *and* its level-data scope —
-     * and the fetch Card payload carries neither, so the host passes this from
-     * the route while the level is parsed from `contextKey`.
-     *
-     * Left null, EntityList keeps the compact renderer: without the scope the
-     * table would draw its columns and never a row.
-     */
-    readonly levelDataId: _angular_core.InputSignal<string | number | null>;
     readonly loading: _angular_core.WritableSignal<boolean>;
     readonly error: _angular_core.WritableSignal<string | null>;
     readonly response: _angular_core.WritableSignal<PreviewResponse | null>;
-    /**
-     * Runtime scope handed to each `EntityList` entity, or null when this host
-     * did not supply a level-data row. See {@link levelDataId}.
-     */
-    protected readonly entityListContext: _angular_core.Signal<EntityListPreviewContext | null>;
     readonly entities: _angular_core.Signal<EntityData[]>;
     /**
      * Name of the schema the loaded record belongs to — the level name for a
@@ -144,11 +152,21 @@ declare class ClientInstancePreview implements OnDestroy {
      * fetch resolves.
      */
     readonly schemaName: _angular_core.Signal<string | null>;
+    /**
+     * What the nested renderers fetch with.
+     *
+     * The level id is taken from the response when the host did not supply one —
+     * `fetch/records` resolves it anyway, so a host that already passes a
+     * `contextKey` should not have to repeat it. The level-data id has no such
+     * fallback: the response's `scopeId` is the level-module id, so a host that
+     * omits `runtimeContext` gets no inline table.
+     */
+    private readonly runtimeContext;
     constructor();
     load(config: ClientInstancePreviewConfig): void;
     ngOnDestroy(): void;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<ClientInstancePreview, never>;
-    static ɵcmp: _angular_core.ɵɵComponentDeclaration<ClientInstancePreview, "mt-client-instance-preview", never, { "config": { "alias": "config"; "required": true; "isSignal": true; }; "hideEmptyState": { "alias": "hideEmptyState"; "required": false; "isSignal": true; }; "stackOnNarrow": { "alias": "stackOnNarrow"; "required": false; "isSignal": true; }; "levelDataId": { "alias": "levelDataId"; "required": false; "isSignal": true; }; }, {}, never, never, true, never>;
+    static ɵcmp: _angular_core.ɵɵComponentDeclaration<ClientInstancePreview, "mt-client-instance-preview", never, { "config": { "alias": "config"; "required": true; "isSignal": true; }; "hideEmptyState": { "alias": "hideEmptyState"; "required": false; "isSignal": true; }; "stackOnNarrow": { "alias": "stackOnNarrow"; "required": false; "isSignal": true; }; }, {}, never, never, true, never>;
 }
 
 declare class ClientInstancePreviewApiService {
@@ -161,4 +179,4 @@ declare class ClientInstancePreviewApiService {
 }
 
 export { ClientInstancePreview, ClientInstancePreviewApiService };
-export type { ClientInstancePreviewConfig, ClientInstancePreviewEntityTransform, DisplayConfiguration, PreviewFetchCatalog, PreviewFetchPropertyMeta, PreviewFetchRecord, PreviewFetchRecordResponse, PreviewFetchSchema, PreviewFetchValueCell, PreviewResponse, Response };
+export type { ClientInstancePreviewConfig, ClientInstancePreviewEntityTransform, DisplayConfiguration, PreviewFetchCatalog, PreviewFetchContext, PreviewFetchPropertyMeta, PreviewFetchRecord, PreviewFetchRecordResponse, PreviewFetchSchema, PreviewFetchValueCell, PreviewResponse, Response };

package/types/masterteam-client-components-client-list.d.ts

@@ -170,6 +170,9 @@ interface ClientListTableDisplayConfig {
      * The key must name a column that is actually rendered, and grouping only
      * makes sense once every row of a group is loaded — with backend paging a
      * group is split across pages and each page grows its own header.
+     *
+     * Also the board's starting grouping: table and cards share one toolbar
+     * state per list, seeded once by whichever view renders first.
      */
     groupBy?: string;
 }
@@ -192,15 +195,23 @@ interface ClientListFormConfiguration extends ClientListBaseConfiguration {
     /** Complete filter array forwarded unchanged to `fetch/query`. */
     filters?: ClientListFetchRequestFilter[];
     /**
-     * `areaType: 'table'` only — fetch the rows owned by this root's
-     * descendants instead of the rows owned by the context's own records. See
-     * {@link ClientListFetchHierarchyScope}. Ignored for cards and informative
-     * lists, which the backend rejects outright.
+     * `areaType: 'table'` and `areaType: 'cards'` — fetch the rows owned by this
+     * root's descendants instead of the rows owned by the context's own records.
+     * See {@link ClientListFetchHierarchyScope}. Ignored for informative lists,
+     * which the backend rejects outright.
      *
      * Rows then arrive from several owners at once: each carries its owning
-     * record under {@link CLIENT_LIST_RECORD_SOURCE_KEY}, row actions are
-     * addressed to that owner's context, and `state.totals` / `state.sourceGroups`
-     * carry the pre-pagination aggregates.
+     * record under {@link CLIENT_LIST_RECORD_SOURCE_KEY} (a card carries it as
+     * {@link ClientListCard.source}), row actions are addressed to that owner's
+     * context, and `state.totals` / `state.sourceGroups` carry the
+     * pre-pagination aggregates.
+     *
+     * A cards board is still fetched as a `Table` projection — descendant scope
+     * is table-only on the backend — and re-dressed with the context's authored
+     * card layout. Two consequences: the board shows the module's table
+     * selection, so a property the card layout uses but the table hides cannot
+     * appear on it; and a write reloads the board rather than splicing, for the
+     * same reason a hierarchy table does.
      */
     hierarchy?: ClientListFetchHierarchyScope;
     mode?: ClientListMode;
@@ -237,7 +248,13 @@ interface ClientListFormConfiguration extends ClientListBaseConfiguration {
     table?: ClientListTableDisplayConfig;
     /**
      * Host hook to reshape built columns/rows before render — see
-     * {@link ClientListTableTransform}. Applies to `table` area only.
+     * {@link ClientListTableTransform}.
+     *
+     * On `areaType: 'cards'` it runs over each card's row representation, so a
+     * board offers the same columns the table does — which is what lets
+     * `table.groupBy` name a host-derived column and still group a board. Cells
+     * the transform *adds* become row-only fields (grouping, filters, export);
+     * the card face keeps rendering its own layout and never shows them.
      */
     transformResult?: ClientListTableTransform;
 }
@@ -611,6 +628,14 @@ interface ClientListCard {
     properties: ClientListCardProperty[];
     displayProperties?: Record<string, unknown>;
     entities: EntityData[];
+    /**
+     * Descendant boards only: the record that owns this card. Null on an
+     * ordinary board, where the list's own context is the owner. Travels into
+     * the card's row representation under
+     * {@link CLIENT_LIST_RECORD_SOURCE_KEY}, so row actions address the owner
+     * rather than the aggregation context.
+     */
+    source?: ClientListFetchRecordSource | null;
 }
 type ClientListCardsPayload = ClientListFetchQueryResponse;
 interface ClientListInformativeChartLink {
@@ -646,14 +671,19 @@ interface ClientListBaseState {
     dashboardData: DashboardBuilderData | null;
     rawData: unknown | null;
     /**
-     * Hierarchy tables only: totals over every matching row before pagination,
+     * Hierarchy lists only: totals over every matching row before pagination,
      * so they stay put as the user pages. Undefined for an ordinary list — the
      * backend sends none, and a page sum would not be the same number.
      */
     totals?: ClientListFetchSum[];
     /**
-     * Hierarchy tables only: one entry per owning record, with its full matching
+     * Hierarchy lists only: one entry per owning record, with its full matching
      * count and subtotals plus the ids of its rows on the current page.
+     *
+     * On a board that appends pages as the user scrolls, "the current page"
+     * means the page fetched last while `cards` holds every page loaded so far
+     * — so read the counts and subtotals, which cover every matching row,
+     * rather than `recordIds`.
      */
     sourceGroups?: ClientListFetchSourceGroup[];
 }
@@ -787,6 +817,22 @@ declare class ClientListStateService {
     setInformativeResult(key: string, response: ClientListInformativeDashboardPayload | null, config: NormalizedClientListConfiguration): void;
     toggleExpanded(key: string): void;
     private mergeItemState;
+    /**
+     * Runs the host's `transformResult` over a board, so it offers the same
+     * columns the table of the same list does — the ones a host derives
+     * included (a descendant list's level and owning record, say). That is what
+     * lets a board group, filter and export by them, and what lets a
+     * `table.groupBy` default naming a derived column group a board at all.
+     *
+     * The card face is left alone: the card keeps rendering its own layout, and
+     * the derived cells ride on `displayProperties`, which only the card's row
+     * representation reads. Cells the transform rewrote rather than added are
+     * not carried over — the card already shows those fields its own way.
+     *
+     * Without a transform the board keeps its old behaviour: no `columns`, so
+     * the view derives them from the first card's entities.
+     */
+    private shapeCards;
     private toCards;
     private orderRecords;
     private resolvePrimarySchema;
@@ -957,11 +1003,14 @@ declare class ClientList implements OnDestroy {
     private resolveType;
     private resolveMode;
     /**
-     * Descendant scope only survives where the backend accepts it: a table, with
-     * a usable root id. Anywhere else it is dropped rather than sent, because
-     * the backend answers an unsupported combination with a 400 that takes the
-     * whole list down — a cards area that happens to share a config object would
-     * otherwise render nothing at all.
+     * Descendant scope only survives where it can actually be fetched: a table
+     * or a cards board, with a usable root id. An informative dashboard drops it
+     * rather than sending it, because the backend answers an unsupported
+     * combination with a 400 that takes the whole list down.
+     *
+     * A cards board does not send it as `Card` either — the backend takes
+     * descendant scope on `Table` only. `ClientListApiService.getCards` fetches
+     * the hierarchy table and re-dresses it as cards.
      */
     private resolveHierarchyScope;
     private toNormalizedConfig;
@@ -1026,6 +1075,8 @@ declare class ClientListApiService {
     private readonly http;
     private readonly runtimeFetchBaseUrl;
     private readonly informativeBaseUrl;
+    /** Card layouts already read back, keyed by context. See {@link getCardLayout}. */
+    private readonly cardLayouts;
     /**
      * Fetches a table page. Resolves to the response **and** the `propertyKeys`
      * the request carried, because a write that wants its record projected the
@@ -1045,7 +1096,49 @@ declare class ClientListApiService {
      * having moved out of the root's subtree since it was written.
      */
     getRecord(contextKey: ClientListRuntimeContext, request: ClientListReturnRecordRequest, filters: ClientListFetchRequestFilter[]): Observable<Response<ClientListFetchQueryResponse>>;
-    getCards(contextKey: ClientListRuntimeContext, filters?: ClientListFetchRequestFilter[], skip?: number, take?: number): Observable<Response<ClientListCardsPayload>>;
+    /**
+     * Fetches a board of cards.
+     *
+     * Without a `hierarchy` scope this is a plain `Card` projection. With one it
+     * cannot be: the backend accepts descendant scope on the **`Table`
+     * projection only** and answers any other projection with a 400 that takes
+     * the whole list down. So a descendant board is fetched as a hierarchy table
+     * and re-dressed as cards — the rows carry the same records, their owning
+     * record and the pre-pagination totals, and {@link getCardLayout} supplies
+     * the card layout the board would otherwise lose.
+     */
+    getCards(contextKey: ClientListRuntimeContext, filters?: ClientListFetchRequestFilter[], skip?: number, take?: number, hierarchy?: ClientListFetchHierarchyScope | null): Observable<Response<ClientListCardsPayload>>;
+    /**
+     * The card layout authored for a context, with every property key rewritten
+     * to its normalized form.
+     *
+     * A `Card` response names its properties by the owning context's own key
+     * (`leveldatafinancial_title`), while a hierarchy response normalizes every
+     * row, column and catalog entry across the child levels down to the shared
+     * key (`title`). Sent through unchanged the layout would resolve against
+     * nothing and every card would render empty.
+     *
+     * Cached per context for the life of the app: it is a second request on a
+     * path that already makes one, it is pure configuration, and it is re-read
+     * on the next full load anyway. A card layout edited in the control panel
+     * therefore needs a reload of the app to show up on a descendant board —
+     * the same page-load boundary the rest of the display configuration has.
+     */
+    private getCardLayout;
+    private toNormalizedDisplayOrder;
+    /**
+     * Dresses a hierarchy table response as the card payload the board reads:
+     * the same records, plus the authored card layout narrowed to the properties
+     * this response actually carries. A layout entry with no property behind it
+     * would render as a nameless blank slot, so it is dropped — section markers
+     * excepted, since they are layout rather than data and have no property to
+     * begin with.
+     *
+     * Leaves the response untouched when there is no usable layout: the card
+     * mapper then falls back to the response's own table columns, which is a
+     * plainer board but a complete one.
+     */
+    private withCardLayout;
     getInformativeDashboard(levelId: number, moduleId: number): Observable<Response<ClientListInformativeDashboardPayload>>;
     private queryRuntime;
     private resolveTablePropertyKeys;