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

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