113 lines
5.8 KiB
Markdown
113 lines
5.8 KiB
Markdown
# 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).
|
|
```
|