Version 3.5.0 collection payload release

docs/admin-forms-access-parity/README.md

@@ -0,0 +1,126 @@
+# Admin Forms Access Parity Plan
+
+This document captures the current Admin Forms review against Microsoft Access-style
+form design and data-entry expectations. It focuses on gaps that affect whether
+CSharpDB forms can compete with Access for database-backed line-of-business apps.
+
+## Current Baseline
+
+The current forms surface already includes:
+
+- drag/drop absolute-layout designer
+- generated forms from table and view schema
+- database-backed form metadata
+- runtime data entry with create, update, delete, paging, and navigation
+- record search and go-to-primary-key navigation
+- labels, text, textarea, number, date, checkbox, radio, select, lookup,
+  computed, data grid, and child-tabs controls
+- lookup lists loaded from tables
+- computed fields with simple formulas and child-table aggregates
+- one-to-many child grids and nested child tabs
+- print support
+- schema-change warnings
+- designer undo/redo, copy/paste, duplicate, layers, alignment, tab order, and
+  mobile/tablet/desktop breakpoint editing
+
+## Added Review Findings
+
+### P1: Runtime ignores responsive form layouts
+
+The designer stores mobile and tablet overrides in `RendererHints`, but the
+runtime renderer always uses `ControlDefinition.Rect`. Any breakpoint layout work
+saved in the designer will not affect actual data-entry rendering.
+
+Primary code path:
+
+- `src/CSharpDB.Admin.Forms/Components/Designer/FormRenderer.razor`
+- `src/CSharpDB.Admin.Forms/Components/Designer/DesignerState.cs`
+
+Expected fix:
+
+- Add a runtime breakpoint/layout resolver shared with the designer.
+- Render controls from the effective breakpoint rectangle, not only the desktop
+  rectangle.
+- Honor breakpoint visibility at runtime.
+- Add renderer tests for desktop, tablet, and mobile overrides.
+
+### P1: Inferred validation is not enforced
+
+`InferRules` creates required, range, regex, and one-of rules, but `Evaluate`
+currently checks only `maxLength` and manually added `required` rules. Default
+generated forms can save invalid required, range, regex, or enum data unless the
+database rejects it later.
+
+Primary code path:
+
+- `src/CSharpDB.Admin.Forms/Services/DefaultValidationInferenceService.cs`
+- `src/CSharpDB.Admin.Forms/Services/DefaultFormGenerator.cs`
+
+Expected fix:
+
+- Evaluate inferred `required`, `maxLength`, `range`, `regex`, and `oneOf`
+  rules for generated controls.
+- Keep validation override behavior intact.
+- Normalize numeric and choice values before comparing.
+- Add tests for generated forms and override combinations.
+
+## Access-Parity Roadmap
+
+### Phase 1: Correctness Before Expansion
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Runtime breakpoint rendering | Planned | Make mobile/tablet designer work visible in data entry. |
+| Complete inferred validation | Planned | Enforce generated required/range/regex/choice rules before save. |
+| Form runtime regression tests | Planned | Cover renderer layout, validation, lookup, computed, and child grid behavior. |
+
+### Phase 2: Record Source, Filtering, and Sorting
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| First-class record source model | Planned | Move beyond a single `TableName`; support table, view, and saved SQL/query sources with editability metadata. |
+| Default filter and default sort | Planned | Store form-level defaults and apply them in the runtime record service. |
+| User sorting | Planned | Let operators sort by visible/searchable fields at runtime. |
+| Advanced filtering | Planned | Add filter-by-field, filter-by-selection, multi-condition filters, saved filters, and clear-filter flows. |
+
+### Phase 3: Access-Style Form Experiences
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Layout View | Planned | Let designers adjust a form while real data is visible. |
+| Multiple form modes | Planned | Add Single Form, Multiple Items, Datasheet, and Split Form equivalents. |
+| Form sections | Planned | Add header, detail, footer, and optional print sections. |
+| Embedded subforms | Planned | Support arbitrary embedded form definitions, not only child grids/tabs. |
+
+### Phase 4: Actions, Events, and App Behavior
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Command button control | Planned | Add buttons that can run form actions. |
+| Action model | Planned | Support actions such as open form, save, delete, navigate, apply filter, clear filter, run SQL/procedure, and show message. |
+| Event hooks | Planned | Add form/control events such as on load, before save, after save, before field change, after field change, and button click. |
+| Conditional UI rules | Planned | Add visible/enabled/read-only expressions for controls. |
+
+### Phase 5: Broader Control and Property Coverage
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Control palette expansion | Planned | Add list box, option group, toggle button, image, attachment/blob, chart, navigation, line, rectangle, page break, and subreport-like controls. |
+| Formatting properties | Planned | Add font, color, border, alignment, numeric/date format, input mask, default value, and required indicators. |
+| Lookup improvements | Planned | Add searchable combo behavior, display/value column configuration, row limits, and dependent lookups. |
+| Child grid improvements | Planned | Add typed editors, validation, sort/filter, column sizing, and batch edit behavior. |
+
+## Product Positioning
+
+The current implementation is a strong database-backed generated-form system.
+To credibly compete with Microsoft Access as an app builder, the next work should
+move from "render fields over records" toward "design complete data-entry
+workflows." The highest leverage model changes are:
+
+- runtime layout resolver
+- full validation engine
+- richer record-source/filter/sort model
+- action/event model
+- form-mode model
+
+Those foundations should be added before expanding the control palette too far.

docs/admin-reports-access-parity/README.md

@@ -0,0 +1,151 @@
+# Admin Reports Access Parity Plan
+
+This document captures the current Admin Reports review against Microsoft
+Access-style report design, preview, print, and distribution expectations. It
+focuses on gaps that affect whether CSharpDB reports can compete with Access for
+database-backed operational reporting.
+
+## Current Baseline
+
+The current reports surface already includes:
+
+- visual band-based report designer
+- database-backed report metadata
+- report sources from tables, views, and supported saved queries
+- default report generation from source schema
+- page settings for Letter/A4, portrait/landscape, and margins
+- report header, page header, detail, page footer, report footer, group header,
+  and group footer bands
+- grouping and sorting definitions
+- labels, bound text, calculated text, lines, and boxes
+- calculated expressions for page number, print date, field references, numeric
+  arithmetic, and `SUM`/`COUNT`/`AVG`/`MIN`/`MAX` aggregates
+- preview pagination with page headers and footers
+- print support through the browser
+- schema-drift warnings
+
+## Added Review Findings
+
+### P1: Saved-query previews are unbounded before trimming
+
+Saved-query reports execute `source.BaseSql` directly and only trim rows after
+the full result has been materialized in memory. Large saved queries can make
+preview slow, memory-heavy, or effectively unusable. Table and view reports use
+the preview query builder with a row limit, but saved-query reports bypass that
+path.
+
+Primary code path:
+
+- `src/CSharpDB.Admin.Reports/Services/DefaultReportPreviewService.cs`
+- `src/CSharpDB.Admin.Reports/Services/ReportPreviewQueryBuilder.cs`
+
+Expected fix:
+
+- Apply the preview row cap before materializing saved-query results.
+- Preserve report group/sort ordering by wrapping the saved query or using an
+  equivalent safe query-builder path.
+- Keep saved-query SQL validation parameterless unless parameter support is
+  added in the same work.
+- Add tests that prove large saved-query previews fetch only the capped row
+  window.
+
+### P2: Preview and print are capped, with no full output/export pipeline
+
+The preview service intentionally caps output at `10,000` rows and `250` pages.
+That is reasonable for an interactive preview, but Access-style reports also
+need a full render/export path for print-ready output and distribution.
+
+Primary code path:
+
+- `src/CSharpDB.Admin.Reports/Services/DefaultReportPreviewService.cs`
+- `src/CSharpDB.Admin.Reports/Pages/Preview.razor`
+
+Expected fix:
+
+- Separate preview rendering from full report rendering.
+- Add export targets such as PDF, HTML, CSV, and spreadsheet-friendly output.
+- Keep preview caps for the UI, but make full export explicit and cancellable.
+- Show clear warnings when printing a capped preview rather than the full report.
+
+## Access-Parity Roadmap
+
+### Phase 1: Runtime Safety and Output Foundations
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Bounded saved-query previews | Planned | Apply preview row limits before materializing saved-query results. |
+| Full report render pipeline | Planned | Separate capped preview from full print/export rendering. |
+| Export support | Planned | Add PDF first, then HTML, CSV, and spreadsheet-friendly exports. |
+| Print warnings | Planned | Make truncated preview printing explicit in the UI. |
+
+### Phase 2: Record Sources, Parameters, and Filters
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Parameterized report sources | Planned | Support saved query/report parameters with prompt UI and typed values. |
+| Runtime filters | Planned | Let users run a report with ad hoc filters without editing the design. |
+| Saved report filter definitions | Planned | Store default filters with the report definition. |
+| Source query builder integration | Planned | Let reports be based on query-designer definitions, not only raw tables/views/saved queries. |
+
+### Phase 3: Grouping, Totals, and Pagination Semantics
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Grouping options | Planned | Add group intervals, header/footer toggles, keep together, repeat section, and force-new-page behavior. |
+| Running totals | Planned | Add per-group and whole-report running sums. |
+| Total placement helpers | Planned | Add guided totals in group headers, group footers, report header, and report footer. |
+| Page header/footer options | Planned | Support Access-style choices such as suppressing page headers on report-header/report-footer pages. |
+| Overflow behavior | Planned | Add text growth/shrink, clipping rules, and band overflow tests. |
+
+### Phase 4: Design Productivity
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Layout View | Planned | Let users adjust a report while seeing real data. |
+| Report Wizard | Planned | Guide source, fields, grouping, sorting, layout, and totals selection. |
+| Label Wizard | Planned | Generate printable mailing/product labels from source fields. |
+| Style themes | Planned | Add reusable report styles for fonts, spacing, borders, and colors. |
+
+### Phase 5: Broader Report Controls and Formatting
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Control palette expansion | Planned | Add image/logo, rich text, barcode, chart, page break, subreport, and attachment/blob controls. |
+| Conditional formatting | Planned | Add value/expression-based formatting rules for report controls. |
+| Data bars and highlights | Planned | Add visual summaries for numeric ranges and thresholds. |
+| Advanced formatting | Planned | Add borders, fill colors, font styles, text wrapping, alignment, culture-aware formats, and background images. |
+| Subreports | Planned | Embed another report definition with parent/child linking. |
+
+### Phase 6: Distribution and Operations
+
+| Feature | Status | Notes |
+| --- | --- | --- |
+| Email/report delivery | Planned | Export and attach reports, with host-provided delivery hooks. |
+| Scheduled reports | Research | Run recurring reports and store generated artifacts. |
+| Report artifact history | Research | Store generated report snapshots for auditing and re-download. |
+| Large-report cancellation | Planned | Add cancellation/progress for long render/export jobs. |
+
+## Product Positioning
+
+The current implementation is a useful printable preview engine with a banded
+designer. To compete with Microsoft Access as a report builder, the next work
+should move toward "reliable report production and distribution." The highest
+leverage foundations are:
+
+- bounded source execution
+- separate preview and full-render pipelines
+- parameter/filter model
+- richer grouping and pagination model
+- export/distribution model
+- conditional formatting and expanded controls
+
+Those foundations should come before broadening the designer surface too far.
+
+## References
+
+- [Introduction to reports in Access](https://support.microsoft.com/en-us/office/introduction-to-reports-in-access-e0869f59-7536-4d19-8e05-7158dcd3681c)
+- [Create a simple report](https://support.microsoft.com/en-us/office/create-a-simple-report-408e92a8-11a4-418d-a378-7f1d99c25304)
+- [Create a grouped or summary report](https://support.microsoft.com/en-au/office/create-a-grouped-or-summary-report-f23301a1-3e0a-4243-9002-4a23ac0fdbf3)
+- [Summing in reports](https://support.microsoft.com/en-us/office/summing-in-reports-ad4e310d-64e9-4699-8d33-b8ae9639fbf4)
+- [Highlight data with conditional formatting](https://support.microsoft.com/en-us/office/highlight-data-with-conditional-formatting-7f7c0bd4-7c37-421d-adad-a260125c8129)
+- [Distribute a report](https://support.microsoft.com/en-us/office/distribute-a-report-561a9066-00ab-41ee-8f07-a0734810a778)