AyCode.Blazor/AyCode.Blazor.Components/docs/MGGRID/MGGRID_ISSUES.md

MGGRID — Known Issues

For planned/actionable work see MGGRID_TODO.md. In-code TODOs are recorded as TODO entries (ACBLAZOR-GRID-T-*) there, since they describe unfinished work rather than confirmed broken behaviour.

ACBLAZOR-GRID-I-N7K2: InfoPanel.SetEditMode crashes the WASM renderer when DxGrid produces no edit model

Severity: Major (unhandled exception killed the renderer) · Status: Closed (2026-07-12) · Area: Components/Grids/MgGridBase.cs → OnCustomizeEditModel

Description

Clicking the toolbar Edit button could crash the entire WebAssembly renderer with System.ArgumentNullException: editModel thrown by MgGridInfoPanel.SetEditMode. Observed on a ProductDto grid right after a datasource reload (OnDataSourceLoaded → immediate Edit click): DevExpress StartEditRowAsync raised CustomizeEditModel with e.EditModel == null (stale FocusedRowVisibleIndex → null data item), and OnCustomizeEditModel passed the null straight to SetEditMode, whose ArgumentNullException.ThrowIfNull escalated to an unhandled rendering exception.

Root cause

MgGridBase.OnCustomizeEditModel captured (e.EditModel as TDataItem)! (null-forgiving cast) with no null check, and on the Edit path (IsNew == false) nothing validated it before InfoPanelInstance.SetEditMode. The local was also captured BEFORE the OnGridCustomizeEditModel consumer callback — so a consumer-created edit model (the official DevExpress pattern for types without a parameterless constructor) never reached the InfoPanel either.

Resolution (2026-07-12)

OnCustomizeEditModel hardened: null-tolerant cast, guarded IsNew branch, the edit model is re-read AFTER the consumer callback, and when it is still null the InfoPanel stays in view mode with a Logger.Warning ([GridName] CustomizeEditModel produced no edit model...) instead of crashing.

Known workaround

None needed after the fix.

Related TODO

None.

ACBLAZOR-GRID-I-K5R3: InfoPanel built-in toolbar edit tools are not configurable

Severity: Minor (UX / consistency gap; can re-open a crash path on listing-only grids) · Status: Open · Area: Components/Grids/MgGridInfoPanel.razor (built-in toolbar) + MgGridToolbarTemplate

Description

MgGridInfoPanel renders its built-in toolbar with hardcoded defaults (MgGridInfoPanel.razor:20: <MgGridToolbarTemplate Grid="_currentGrid" OnlyGridEditTools="true" ShowOnlyIcon="true" />), so EnableNew / EnableEdit are always true there. When a consumer disables New/Edit on its own master toolbar (e.g. a listing-only grid such as a product grid whose data is managed in an external admin and has no Add/Update SignalR tags), the InfoPanel toolbar still offers + and edit — the edit flow can be started through a side door the consumer cannot close.

Root cause

The panel's toolbar instance is not parameterizable from the outside, and there is no grid-level edit-enable flag the toolbar could consult — the Enable* flags live only on individual MgGridToolbarTemplate instances.

Known workaround

None from the consumer side (the panel toolbar cannot be reached). Master-toolbar EnableNew="false" EnableEdit="false" covers the primary path only.

Proposed fix

Grid-level EditItemsEnabled parameter on MgGridBase / IMgGridBase (default true); MgGridToolbarTemplate computes effective enablement as own Enable* && Grid.EditItemsEnabled, so both the master and the built-in InfoPanel toolbar respect a single consumer declaration.

Related TODO

None yet — becomes a TODO when scheduled.

ACBLAZOR-GRID-I-D4T7: Roamed layout with quick-filter criteria cannot be cleared where the grid has no FilterPanel

Severity: Minor (rare version-/markup-skew scenario) · Status: Open · Area: Components/Grids/MgGridBase.cs (filter-panel reconcile) + layout roaming (MGGRID_LAYOUT.md)

Description

Filter-panel criteria persist inside the grid layout (GridPersistentLayout.FilterCriteria) — including the server-roamed UserSave tier. On restore the grid reconciles the registered FilterPanel controls: visible panel → the controls re-select from the criteria; hidden panel → the controls' own criteria is cleared (a panel filter must never filter invisibly). BUT the reconcile identifies panel-owned fields from the registered controls. If a layout saved by a grid WITH a FilterPanel is loaded where the same grid has NO panel at all (older client build, or a page variant without the panel), no controls register → the panel criteria stays applied invisibly (shape alone is not enough to strip it safely — an IN can also come from legitimate header-filter use).

Root cause

Field ownership ("this criteria belongs to a filter-panel component") exists only at runtime via component registration + shape recognition (IMgGridFilterPanelComponent.OwnsCriteria); the persisted layout does not record which fields were panel-owned.

Known workaround

Reset layout (toolbar) on the affected client, or re-save the layout from a client that has the panel.

Proposed fix

Wrap the persisted layout in an MgGrid envelope (MgGridLayoutSave { Version, GridLayoutJson, FilterPanelLayoutJson }) so panel state never rides inside the DevExpress layout: an entry no component claims simply never reaches the grid — this issue is then closed by construction, no clearing logic needed. Design in ADR 0004 (AyCode.Core repo) → "Planned v2".

Related TODO

MGGRID_TODO.md#acblazor-grid-t-w8q3 (the envelope + pull-model restore — closes this issue).

Issue entry template

## ACBLAZOR-GRID-I-XXXX: Short title

**Severity:** Trivial / Low / Minor / Major · **Status:** Open / Documented / Mitigated · **Area:** <subsystem>

### Description
What breaks, and under what conditions.

### Root cause
Why it happens (code location + design mismatch).

### Known workaround
Steps a consumer can take until fixed.

### Related TODO
`MGGRID_TODO.md#acblazor-grid-t-XXXX` (if applicable).