# 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 (`{ dxLayout, quickFilterFields[] }`) so the loader can clear
quick-filter fields even with no registered controls. Deliberately deferred until the scenario is actually hit
(YAGNI); referenced from ADR 0004 (AyCode.Core repo).

### Related TODO
None yet.

## 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).
```