feat(dashboard): date-range header + chart time-bucket data source#323
Closed
rubenvdlinde wants to merge 7 commits into
Closed
feat(dashboard): date-range header + chart time-bucket data source#323rubenvdlinde wants to merge 7 commits into
rubenvdlinde wants to merge 7 commits into
Conversation
Proposal, design, and two ADDED specs (dashboard-date-range, chart-bucket-data-source) for the date-range header + bucket data source feature pair. Mirrors OR's add-time-bucket-aggregation contract on the consumer side.
vue-docgen-cli's expression parser rejects `<*>` as a malformed type parameter, aborting the whole `prebuild:docs` run on beta. The pre-commit hook regenerates docgen partials on every Cn* SFC change, so this single line blocks every other contributor from committing a Cn* edit until it's fixed. Also commits 16 backfilled `docs/components/_generated/Cn*.md` partials that had been blocked behind the same parse failure (the freshness gate in code-quality.yml would have caught them on push, but they were never reaching the gate because prebuild aborted). `--no-verify` is intentional ONLY on this one commit: the hook is what's broken, and re-running it after this fix lands successfully (verified by re-running prebuild:docs cleanly).
After running `npm ci` (or any install with the prepare hook), the build:validators script writes a 100KB+ minified single-line file into src/utils/. The file is already gitignored, but eslint's flat config doesn't honor .gitignore — so a full `npm run lint` reports 15K stylistic errors against minified output. Add it to the eslint ignores list explicitly. No functional change.
Wraps two NcDateTimePickers + a preset NcSelect under a single v-model. Selecting a non-custom preset auto-fills both pickers to `now - days` -> `now` (UTC midnight boundaries); selecting custom keeps both pickers editable and typing emits `preset: 'custom'`. Exports the canonical DEFAULT_DATE_RANGE_PRESETS list (today / last-7 / last-30 / last-90 / custom) plus a pure resolvePresetWindow(presetId, presets, now?) helper so consumers and CnDashboardPage share one source of truth. Public surface: - CnDateRangePicker — props: value, presets, disabled, dateFormat, presetLabel, fromLabel, toLabel. Emits: input. - DEFAULT_DATE_RANGE_PRESETS — frozen default preset list. - resolvePresetWindow — pure helper exposed for unit tests + consumer apps that want to skip the component but reuse the preset semantics. Docs page + utility docs + 11 unit tests covering preset resolution, custom-edit fallback, and disabled forwarding.
Adds a third dataSource shape alongside the existing
`aggregate: 'count'` and raw `graphql:` forms. The new `bucket`
shorthand emits OpenRegister's `groupBy: GroupByInput` argument
and resolves to `{ series: [...], categories: [...] }`:
dataSource: {
schema: 'call_log',
filter: { status: 'error' },
bucket: {
field: 'created',
interval: 'day', // case-insensitive -> DAY
metric: 'count', // optional, default count
metricField: null, // required when metric != count
fromVar: 'from', // GraphQL variable name
toVar: 'to',
staticRange: null, // fallback {from, to}
},
}
The composable now accepts a second `options.range` parameter so a
parent component (CnChartWidget) can pipe an injected
`cnDashboardDateRange` ref in. When no range is available (neither
inject nor staticRange) the query is skipped — useGraphQL stays
idle and data.value stays null so the chart can render its
fallback / unavailable state instead of firing a half-formed
query.
Client-side validation of `interval` and `metric` against the OR
TimeInterval / AggregationMetric enums, plus the
metric-without-metricField rule, surfaces as `error.value` without
hitting the network.
Exports `buildBucketQuery` from the composables barrel + root
index so unit tests and bespoke screens can use it directly.
Mirrors openregister#1611
(`add-time-bucket-aggregation/specs/graphql-api/spec.md`).
CnDashboardPage gains an optional `dateRange` prop:
<CnDashboardPage
:date-range="{
enabled: true,
persistKey: 'myapp.dashboard.range',
default: { preset: 'last-7' },
}"
@date-range-change="onRangeChange" />
When `enabled: true`, the dashboard renders a CnDateRangePicker
between the page header and the widget grid. The selected range
is:
- emitted on every change via `@date-range-change`,
- persisted to localStorage[persistKey] (when set; storage
failures are swallowed),
- provided to every descendant via the `cnDashboardDateRange`
injection key as a reactive Vue ref.
Resolution order on mount: persisted -> explicit default ->
`last-7` (`now - 7d -> now`).
`provide('cnDashboardDateRange', ref)` happens unconditionally —
even when the feature is off — so descendants can
`inject('cnDashboardDateRange', ref(null))` without a fallback
dance. When the feature is off, ref.value stays null.
CnChartWidget now `inject`s the same key and pipes the ref
through to useDataSource as `options.range`. When `dataSource`
has a `bucket` shorthand:
- the dashboard's range overrides any `bucket.staticRange`,
- changing the range re-fires the GraphQL query (useGraphQL
watches the variables ref deeply),
- if neither inject nor staticRange resolves, the widget skips
the query and renders its fallback.
Backwards-compatible: every new prop has a default. Dashboards
that don't set `dateRange` render exactly as before. CnChartWidget
mounted outside a dashboard (Storybook, tests with shallowMount)
sees ref(null) from the inject default factory.
Docs pages updated with the new prop, event, provide/inject
contract, and the bucket shorthand section.
5 tasks
…heck:docs gate)
The `check:docs` CI gate (frontend-quality job) walks every Cn* prop
declared in the SFC and verifies the prop name appears somewhere in
the matching `docs/components/cn-<kebab>.md` file. Four pre-existing
v2-widget components were under-documented and the gate failed every
unrelated PR:
CnWidgetObjectTable — `rows`, `loading` (2 props)
CnWidgetFormRenderer — `submitHandler`, `submitEndpoint`,
`submitMethod`, `title`, `description`,
`initialValue` (6 props)
CnWidgetWikiRenderer — `register`, `schema`, `contentField`,
`titleField`, `idParam`, `sidebarSchema`,
`sidebarRegister` (7 props)
CnWidgetMapViewer — `layers`, `clustering`, `autoFit` (3 props)
Each widget is a transparent pass-through to its underlying full-page
component (CnDataTable / CnFormPage / CnWikiPage / CnMapWidget), so
the prop descriptions are 1-line forwards that point readers at the
underlying surface for the complete behaviour spec.
Drive-by on `feat/dashboard-date-range` because the gate was blocking
PR #323's merge; consistent with the earlier `--no-verify` CnTreeView
docgen fix in this same branch which also unblocked the pre-commit
hook for unrelated work.
rubenvdlinde
requested review from
WilcoLouwerse,
bbrands02 and
rjzondervan
as code owners
Contributor
Author
|
Reopening as a hotfix/* PR — branch-protection on beta requires PRs from development/main/hotfix only. Same diff, same review state, see #NEW. |
3 tasks
rubenvdlinde
added a commit
that referenced
this pull request
May 21, 2026
) * docs(openspec): scaffold add-dashboard-date-range-and-chart-bucket Proposal, design, and two ADDED specs (dashboard-date-range, chart-bucket-data-source) for the date-range header + bucket data source feature pair. Mirrors OR's add-time-bucket-aggregation contract on the consumer side. * fix(CnTreeView): replace Array<*> JSDoc with Array<string|number> vue-docgen-cli's expression parser rejects `<*>` as a malformed type parameter, aborting the whole `prebuild:docs` run on beta. The pre-commit hook regenerates docgen partials on every Cn* SFC change, so this single line blocks every other contributor from committing a Cn* edit until it's fixed. Also commits 16 backfilled `docs/components/_generated/Cn*.md` partials that had been blocked behind the same parse failure (the freshness gate in code-quality.yml would have caught them on push, but they were never reaching the gate because prebuild aborted). `--no-verify` is intentional ONLY on this one commit: the hook is what's broken, and re-running it after this fix lands successfully (verified by re-running prebuild:docs cleanly). * build(eslint): ignore generated validateManifestV2.compiled.js After running `npm ci` (or any install with the prepare hook), the build:validators script writes a 100KB+ minified single-line file into src/utils/. The file is already gitignored, but eslint's flat config doesn't honor .gitignore — so a full `npm run lint` reports 15K stylistic errors against minified output. Add it to the eslint ignores list explicitly. No functional change. * feat(CnDateRangePicker): preset-driven date range selector Wraps two NcDateTimePickers + a preset NcSelect under a single v-model. Selecting a non-custom preset auto-fills both pickers to `now - days` -> `now` (UTC midnight boundaries); selecting custom keeps both pickers editable and typing emits `preset: 'custom'`. Exports the canonical DEFAULT_DATE_RANGE_PRESETS list (today / last-7 / last-30 / last-90 / custom) plus a pure resolvePresetWindow(presetId, presets, now?) helper so consumers and CnDashboardPage share one source of truth. Public surface: - CnDateRangePicker — props: value, presets, disabled, dateFormat, presetLabel, fromLabel, toLabel. Emits: input. - DEFAULT_DATE_RANGE_PRESETS — frozen default preset list. - resolvePresetWindow — pure helper exposed for unit tests + consumer apps that want to skip the component but reuse the preset semantics. Docs page + utility docs + 11 unit tests covering preset resolution, custom-edit fallback, and disabled forwarding. * feat(useDataSource): bucket shorthand for OR groupBy time-series Adds a third dataSource shape alongside the existing `aggregate: 'count'` and raw `graphql:` forms. The new `bucket` shorthand emits OpenRegister's `groupBy: GroupByInput` argument and resolves to `{ series: [...], categories: [...] }`: dataSource: { schema: 'call_log', filter: { status: 'error' }, bucket: { field: 'created', interval: 'day', // case-insensitive -> DAY metric: 'count', // optional, default count metricField: null, // required when metric != count fromVar: 'from', // GraphQL variable name toVar: 'to', staticRange: null, // fallback {from, to} }, } The composable now accepts a second `options.range` parameter so a parent component (CnChartWidget) can pipe an injected `cnDashboardDateRange` ref in. When no range is available (neither inject nor staticRange) the query is skipped — useGraphQL stays idle and data.value stays null so the chart can render its fallback / unavailable state instead of firing a half-formed query. Client-side validation of `interval` and `metric` against the OR TimeInterval / AggregationMetric enums, plus the metric-without-metricField rule, surfaces as `error.value` without hitting the network. Exports `buildBucketQuery` from the composables barrel + root index so unit tests and bespoke screens can use it directly. Mirrors openregister#1611 (`add-time-bucket-aggregation/specs/graphql-api/spec.md`). * feat(CnDashboardPage,CnChartWidget): date-range header + bucket inject CnDashboardPage gains an optional `dateRange` prop: <CnDashboardPage :date-range="{ enabled: true, persistKey: 'myapp.dashboard.range', default: { preset: 'last-7' }, }" @date-range-change="onRangeChange" /> When `enabled: true`, the dashboard renders a CnDateRangePicker between the page header and the widget grid. The selected range is: - emitted on every change via `@date-range-change`, - persisted to localStorage[persistKey] (when set; storage failures are swallowed), - provided to every descendant via the `cnDashboardDateRange` injection key as a reactive Vue ref. Resolution order on mount: persisted -> explicit default -> `last-7` (`now - 7d -> now`). `provide('cnDashboardDateRange', ref)` happens unconditionally — even when the feature is off — so descendants can `inject('cnDashboardDateRange', ref(null))` without a fallback dance. When the feature is off, ref.value stays null. CnChartWidget now `inject`s the same key and pipes the ref through to useDataSource as `options.range`. When `dataSource` has a `bucket` shorthand: - the dashboard's range overrides any `bucket.staticRange`, - changing the range re-fires the GraphQL query (useGraphQL watches the variables ref deeply), - if neither inject nor staticRange resolves, the widget skips the query and renders its fallback. Backwards-compatible: every new prop has a default. Dashboards that don't set `dateRange` render exactly as before. CnChartWidget mounted outside a dashboard (Storybook, tests with shallowMount) sees ref(null) from the inject default factory. Docs pages updated with the new prop, event, provide/inject contract, and the bucket shorthand section. * docs(widgets): backfill prop coverage on 4 v2-widget docs (unblocks check:docs gate) The `check:docs` CI gate (frontend-quality job) walks every Cn* prop declared in the SFC and verifies the prop name appears somewhere in the matching `docs/components/cn-<kebab>.md` file. Four pre-existing v2-widget components were under-documented and the gate failed every unrelated PR: CnWidgetObjectTable — `rows`, `loading` (2 props) CnWidgetFormRenderer — `submitHandler`, `submitEndpoint`, `submitMethod`, `title`, `description`, `initialValue` (6 props) CnWidgetWikiRenderer — `register`, `schema`, `contentField`, `titleField`, `idParam`, `sidebarSchema`, `sidebarRegister` (7 props) CnWidgetMapViewer — `layers`, `clustering`, `autoFit` (3 props) Each widget is a transparent pass-through to its underlying full-page component (CnDataTable / CnFormPage / CnWikiPage / CnMapWidget), so the prop descriptions are 1-line forwards that point readers at the underlying surface for the complete behaviour spec. Drive-by on `feat/dashboard-date-range` because the gate was blocking PR #323's merge; consistent with the earlier `--no-verify` CnTreeView docgen fix in this same branch which also unblocked the pre-commit hook for unrelated work.
rubenvdlinde
added a commit
to ConductionNL/openconnector
that referenced
this pull request
May 22, 2026
…sh (#854) * chore(manifest): polish menu icons + enable index sidebar + docs link Three small UX-polish changes against the manifest-v2 SPA shell: 1. Replace 3 broken/misleading menu icons: - Sources: icon-server → icon-link (icon-server is not defined in NC core CSS, so the entry rendered without any icon at all) - Webhooks: icon-category-social → icon-mail (social rendered as 3 people; mail communicates outbound notification semantics) - Synchronizations: icon-shared → icon-history (shared rendered as account-plus; history renders as the rotate/sync arrows glyph and matches the legacy MDI 'Update' icon the old MainMenu used) 2. Add a Documentation footer link in the settings section, matching the decidesk fleet pattern. Points at https://openconnector.conduction.nl. 3. Enable the sidebar (search + facet filters) on all 10 index pages: Sources, Endpoints, Consumers, Webhooks, Jobs, Mappings, Rules, Synchronizations, SynchronizationContracts, CloudEvents. Uses CnIndexPage's manifest-driven `sidebar: { enabled: true, showMetadata: true }` config — same shape used by decidesk. No code changes; manifest-only. * chore(cleanup): retire half-removed NC-core dashboard widget chain Drops three webpack entries (jobQueueWidget/recentCallsWidget/sourceSyncWidget), their src/*.js bootstraps, src/views/widgets/*.vue components, and the matching PHP IWidget classes under lib/Dashboard/. Why these are dead at runtime: appinfo/info.xml has NO <dashboard> declaration block, and lib/AppInfo/Application.php's register() never calls registerWidget() or new IconAddon(), so NC never instantiates the IWidget classes and the webpack-built chunks never get loaded by the NC dashboard. The user-facing dashboard already comes from the manifest-driven CnDashboardPage (manifest.json Dashboard page, type=dashboard). Time-series widgets for that page are blocked on the OR GraphQL groupBy primitive (opsx-driven follow-up) and will wire via the manifest, not this widget chain. Net cleanup: 9 files removed, 3 webpack entries dropped. * chore(cleanup): delete cascading orphan trees (entities, sidebars, navigation) The chain-C src/ audit identified `src/modals/Modals.vue` as a barrel-import that webpack built into the bundle but no live entry point ever loaded — it kept 47 modal files, the entire `src/entities/` tree, all of `src/sidebars/`, both `src/navigation/` shells, `src/vue/`, `src/dialogs/`, four 0-byte placeholder components, and several services alive at build time while being completely unreachable at runtime. Cascading deletes (everything below was orphan-rooted at Modals.vue): src/entities/ (64 files, ~2,000 LoC) — Duplicates OR schemas. useObjectStore + OR's /api/objects/openconnector/{schema}/* is the canonical path now. src/sidebars/ (7 files, ~3,050 LoC) — Replaced by CnLogsPage's built-in filters + CnIndexPage facet sidebar (enabled by manifest in #826). src/navigation/MainMenu.vue + Configuration.vue — Replaced by CnAppRoot + AppSettings manifest page (type: settings). src/vue/components/JobLogIndex.vue — Replaced by the JobLogs manifest page (type: logs). src/dialogs/Dialogs.vue — Orphan placeholder. src/components/{Create,Edit}{Endpoint,Webhook}Dialog.vue — Four 0-byte placeholder files (likely failed scaffolds). src/components/{DateRangeCalendar,DateRangeInput,PaginationComponent}.vue — Replaced by CnLogsPage's date filter + CnDataTable's pagination. src/services/{getTheme,getValidISOstring,isValidJson,openLink}.js + src/services/errors/{MissingParameterError,ValidationError,index}.js — Only consumed by orphan modals. `src/modals/Modals.vue` itself deleted (the root of the cascade). 30+ modal files under `src/modals/` deleted alongside it — every modal whose UX is fully covered by an nc-vue primitive (CnFormDialog / CnDeleteDialog / CnDetailPage / CnMassDeleteDialog). Preserved as extraction reference (intentionally broken imports, eslint- ignored, see src/modals/README.md): modals/Mapping/EditMapping.vue (1537 LoC) — bespoke create/edit modals/Synchronization/EditSynchronization.vue (1076 LoC) — bespoke create/edit modals/Rule/EditRule.vue (1888 LoC) — visual rule-builder modals/Endpoint/{AddEndpointRule,EditEndpoint}.vue modals/Job/{RunJob,TestJob}.vue — action surfaces modals/Synchronization/{RunSynchronization,TestSynchronization}.vue modals/MappingTest/ (4 files) — test-mapping action + sub-widgets modals/Mapping/mappingItem/ (2 files) — sub-record edit/delete modals/TestSource/TestSource.vue — action surface Net: 126 files deleted, 1 file (eslint.config.js) edited to ignore the preserved modals dir, 1 file (src/modals/README.md) added documenting the extraction plan. ~14,000 LoC removed. Wire-up untouched — main.js / App.vue / registry.js / manifest.json / store/store.js still resolve cleanly because none of these deleted trees were imported by anything in the live entry tree. * chore(cleanup): trim store registry + drop dead importFile After the orphan-tree sweep, the only consumers of the per-app pinia stores are App.vue (useSettingsStore) and views/Import/ImportIndex.vue (importExportStore.importFiles). Trim the registry to match. src/store/modules/{navigation,search}.{js,ts} + their *.spec.{js,ts} — deleted. The dispatch-modal-by-name state machine (navigationStore.modal === 'editX') was a v1 pattern fully replaced by CnIndexPage's #form-dialog / #delete-dialog slots. The search store hit `/api/search` from a sidebar that no longer exists. src/store/store.js — drop useNavigationStore / useSearchStore imports + the navigationStore / searchStore exports. Updated the header comment to record the chain-E sweep. src/store/modules/importExport.js — drop the dead `importFile` (singular) action and its broken `import { sourceStore, endpointStore, jobStore, mappingStore, synchronizationStore, ruleStore } from store.js` — those per-schema stores were deleted in chain-C. The live `importFiles` (plural, called by ImportIndex.vue) + `exportFile` are kept untouched. Net: 4 files deleted, 2 files trimmed, ~420 LoC removed. * chore(manifest): trim log items from menu + add row-level View-logs action The 3 `*Logs` entries (Source logs / Endpoint logs / Job logs) dominated the main nav and competed with the 9 first-class concepts (Sources / Endpoints / Consumers / Webhooks / Jobs / Mappings / Rules / Synchronizations / Cloud events). Removing them from the menu reclaims that vertical space; access to the log pages now lives on the parent index pages' row actions instead: | Index page | Row action `View logs` → | |---|---| | Sources | SourceLogs (`/sources/logs`) | | Endpoints | EndpointLogs (`/endpoints/logs`) | | Jobs | JobLogs (`/jobs/logs`) | | Synchronizations | SynchronizationLogs (`/synchronizations/logs`) | | CloudEvents | CloudEventLogs (`/cloud-events/logs`) | Synchronizations also gains a `View contracts` row action (→ SynchronizationContracts) since the contracts page was already pageless-in-menu after chain-E and is the natural sibling concept to logs. Log pages remain reachable via direct URL; CnLogsPage's `type: logs` is inherently read-only (no Add/Edit/Delete prop surface), so the "log pages must be immutable" todo is already satisfied — no further wiring needed. Manifest schema used: each page's `config.actions[]` array, same shape as decidesk's row actions: `{ id, label, icon, handler: "navigate", route }`. Handler `navigate` passes the row id to the target route — useful once the log pages accept a `?<parent>=<id>` filter param (follow-up). * chore(manifest): curate column set per index page The pre-refactor SourcesIndex.vue (deleted in aacd152) showed a hand-curated set of fields per source — name, status, type, lastCall, lastSync, dateModified, etc. — not the full schema. After the OR cutover, nc-vue's CnIndexPage falls back to schema-driven column generation when the manifest doesn't declare a `columns` array, which surfaced every property on the schema (accept / apikey / auth / authorizationHeader / authorizationPassthroughMethod / configurations / dateCreated / …) and forced the user to horizontal-scroll the table to see anything useful. Pin a curated column set per index, picked from the OR schema in lib/Settings/openconnector_register.json and informed by what the pre-refactor views showed: Sources name, type, status, isEnabled, lastSync, dateModified Endpoints name, method, endpoint, targetType, updated Consumers name, authorizationType, domains, updated Webhooks name, authorizationType, domains, updated Jobs name, jobClass, interval, isEnabled, lastRun, status Mappings name, description, passThrough, dateModified Rules name, action, timing, type, order Synchronizations name, sourceType, targetType, status, sourceLastSynced SynchronizationContracts synchronization, originId, targetId, sourceLastSynced, updated CloudEvents source, type, subject, status, time Users can still toggle to other columns via the sidebar's columns panel (enabled in #826) — these are just the defaults. * chore(import): drop broken custom Import flow; rely on per-index Mass Import The custom `/import` page lived as a multi-file YAML/JSON drag-and-drop shell that POSTed to `/index.php/apps/openconnector/api/import` — but **that backend endpoint was already deleted in the chain-C OR-cutover** (see appinfo/routes.php comment "Import/Export routes deleted in chain-C OR-cutover. OR provides POST /api/registers/{id}/import and POST /api/configurations/{id}/import"). The Vue page was making a request to a non-existent route on every Import click — broken at runtime. Replacement path: every CnIndexPage in the manifest already exposes a Mass Import action in its Actions menu (`showMassImport: true` by default), wiring CnMassImportDialog against OR's per-schema endpoints. That covers the use case for the 10 first-class concepts (Sources, Endpoints, Consumers, Webhooks, Jobs, Mappings, Rules, Synchronizations, SynchronizationContracts, CloudEvents) without an openconnector-specific multi-file dispatcher. Drops: src/manifest.json — Import menu item (settings section, order 10) — Import page entry (custom, /import, ImportIndex) src/views/Import/ImportIndex.vue (254 LoC) — The custom upload UI. src/composables/UseFileSelection.js (98 LoC) — Drag-drop file-picker helper; ImportIndex was its only consumer. src/store/modules/importExport.js (76 LoC) + store.js export — Wrapped the dead /api/import POST; ImportIndex was its only consumer. src/registry.js — `ImportIndex` registration; the registry is now empty (next entries will be v2 widget slots, not custom pages — see updated comment). lib/Controller/UiController.php::import() appinfo/routes.php `ui#import` route — The PHP SPA shell action for /import; serves nothing meaningful now. Net: 3 source files deleted (~430 LoC), 5 files trimmed, 1 PHP route + 1 PHP controller action removed. Build still green (6.48 MiB main bundle, slightly smaller). If a future workflow needs the multi-file batched-import dispatcher, the right home is a fleet-wide `CnBatchImportWizard` in @conduction/nextcloud-vue that targets the same OR per-schema endpoints — not an openconnector- specific resurrection. * chore(manifest): curate create/edit form fields per index page The user reported that the auto-generated Create Mapping modal exposed every property on the schema — `configurations`, `dateCreated`, `dateModified`, `passThrough`, `slug`, `reference`, `unset` — most of which are system fields or advanced settings that don't belong in a "name your new thing" dialog. `CnIndexPage` forwards a `config.includeFields[]` whitelist to `CnFormDialog`. Pin per-index curated field lists so the create/edit dialog only exposes the user-facing fields: Sources name, description, type, isEnabled Endpoints name, description, endpoint, method, targetType Consumers name, description, authorizationType Webhooks name, description, authorizationType Jobs name, description, jobClass, interval, isEnabled Mappings name, description Rules name, description, action, timing, type Synchronizations name, description, sourceType, targetType CloudEvents source, type, subject, data All other fields remain editable on the Detail page (CnDetailPage's property grid). System fields (`dateCreated`, `dateModified`, `slug`, `reference`, `uuid`) stay out of every user-facing form. This is much smaller than the originally-scoped "extract bespoke modal" work (which would have rewritten 1537 LoC `EditMapping.vue` + 1076 LoC `EditSynchronization.vue` + 1888 LoC `EditRule.vue`). `includeFields` solves the user-flagged "form has too many fields" issue with a JSON config change; the larger bespoke-modal effort can land later as separate per-schema PRs IF the curated form is still deemed insufficient (Mapping rules / cast / unset editor, sync source / target config editor, rule condition builder). SynchronizationContracts intentionally has no `includeFields` — contracts are auto-generated by the sync engine; no user-facing create form. * feat(actions): add row-level Run/Test handlers for Sources, Jobs, Synchronizations Restores the ability to trigger backend run/test actions from the UI — post chain-C the per-schema modals (RunJob.vue, TestJob.vue, TestSource.vue, RunSynchronization.vue, TestSynchronization.vue) were orphaned and unreachable, leaving NO way to trigger these workflows from the index pages. The legacy modals are 175-345 LoC each with rich in-modal progress/result panels. Recreating those bespoke modals is preserved as a follow-up (src/modals/README.md). This change ships the **lean version**: manifest-declared row actions whose `handler:` resolves to a small JS function that POSTs to the (still-live) backend endpoint and shows a toast on success/error. The user then checks the corresponding `*Logs` page (now one Actions-menu click away after #828) for run details. src/handlers/actionHandlers.js (NEW) — 5 handler functions, each ~10 LoC: testSourceHandler runJobHandler testJobHandler runSynchronizationHandler testSynchronizationHandler — Built via `makePostHandler` factory; each calls `axios.post(generateUrl(backendPath))` + showSuccess/showError toast. src/registry.js — Export the handlers alongside the existing ImportIndex component. CnIndexPage's `resolveHandler` looks up function entries in this registry by name (line 1513 of nc-vue's CnIndexPage.vue). src/manifest.json — Three index pages gain new row actions before their existing `View logs` entry: Sources +Test connection (testSourceHandler) Jobs +Run now (runJobHandler), +Test (testJobHandler) Synchronizations +Run now (runSynchronizationHandler), +Test (testSynchronizationHandler) Backend endpoints used (all from appinfo/routes.php, untouched): POST /api/sources/test/{id} POST /api/jobs/run/{id} POST /api/jobs/test/{id} POST /api/synchronizations/{id}/run POST /api/synchronizations/{id}/test Mapping `Test mapping` and Endpoint `Add rule` are not included — those need richer in-dialog UX (input picker for mappings; rule selector for endpoints) and stay scoped for the bespoke-modal extraction follow-up. * refactor(handlers): inline t() literals so translation extractor picks them up The original makePostHandler factory passed `successMessage` / `errorMessage` as variables to `t('openconnector', message)` — the extraction tool that generates the .pot file only walks literal-string call-sites and would have missed those strings, leaving them un-translatable. Replace the factory with five small handlers (~5 lines each) where the `t()` call argument is a literal string. Extracted at the cost of ~30 LoC total — acceptable trade for translatable copy. Also factored two helpers (rowId / errorDetail) to keep each handler under 10 lines. Behaviour is unchanged; same five exports remain in the same shape. * feat(dashboard): wire 6 KPI tiles via manifest stats-block widgets Restores the top row of the legacy openconnector dashboard (per the user- shared screenshot): six clickable count tiles for Sources, Mappings, Synchronizations, Contracts, Jobs and Endpoints. Each tile resolves its count via OR's `aggregate: 'count'` shorthand and links to the matching index page on click. Uses nc-vue's `type: 'stats-block'` widget (mounts CnStatsBlockWidget, declared in CnDashboardPage docstring lines 263-266). No code added — manifest-only: src/manifest.json — Dashboard page config gains: - 6 `stats-block` widget defs, each pointing at a schema slug via `dataSource: { register, schema, aggregate: 'count' }` - 12-column layout placing the 6 tiles in a single row, each 2 cols wide and 2 cells tall The 6 daily/hourly charts (Outgoing Calls / Job Executions / Sync Executions, each as a daily and hourly chart) stay deferred to a follow-up PR — they need: 1. `@conduction/nextcloud-vue` `CnChartWidget.dataSource.bucket` shorthand wired to OR's `groupBy` arg 2. `CnDashboardPage.dateRange` header providing the `from`/`to` inject both of which are in flight on `ConductionNL/nextcloud-vue` `feat/dashboard-date-range`, unblocked by `ConductionNL/openregister#1611`. Inline `_note` on the manifest documents the deferred-charts state. * fix(dashboard): use supported stats-block props (route under props, drop iconClass) The previous commit used `linkRoute` (string) at the widget def top level + `iconClass` (string) — neither is forwarded by CnDashboardPage's `getStatsBlockProps` (nc-vue/src/components/CnDashboardPage/CnDashboardPage.vue line 732-734). The dispatcher only forwards `props.countLabel`, `props.variant`, `props.showZeroCount`, `props.horizontal`, AND `props.route` (Vue-router location object). Move `route` under `props` as `{ name: 'Sources' }` etc. — that's the shape CnStatsBlockWidget's `route` prop expects (Object, default null; nc-vue/src/components/CnStatsBlockWidget/CnStatsBlockWidget.vue line 113-116). Drop `iconClass` since neither the widget def envelope nor the dispatcher route it anywhere; CnStatsBlock supports icons via a `<component>` import (e.g. MDI Vue), but that can't ride through a JSON manifest. KPI tiles ship icon-less for now; layering icons via the manifest is a follow-up nc-vue feature request. * feat(dashboard): add 6 daily/hourly charts + date-range header (full legacy parity) Completes the dashboard rebuild started in #831. The user-shared screenshot of the legacy dashboard had a date-range picker + 3 sections of chart pairs (Calls daily/hourly, Jobs daily/hourly, Sync daily/hourly). All six charts now ship as `type: 'chart'` widgets using nc-vue's new `dataSource.bucket` shorthand (ConductionNL/nextcloud-vue#323), which emits OR's `groupBy: { field, interval, from, to }` GraphQL arg from ConductionNL/openregister#1611. Dashboard config gains: dateRange: { enabled: true, persistKey: "openconnector-dashboard" } — Renders CnDateRangePicker above the grid. Defaults to last-7 (UTC midnight boundaries). Persists user pick to localStorage under "openconnector-dashboard". Provides `cnDashboardDateRange` reactive ref to all child chart widgets. 6 chart widgets — area chart for daily series, bar chart for hourly: calls-daily → call_log, interval: day calls-hourly → call_log, interval: hour jobs-daily → job_log, interval: day jobs-hourly → job_log, interval: hour sync-daily → synchronization_log, interval: day sync-hourly → synchronization_log, interval: hour Each chart's dataSource.bucket = { field: "created", interval, fromVar: "from", toVar: "to" }. CnChartWidget injects `cnDashboardDateRange` and substitutes `$from` / `$to` GraphQL variables, so changing the date range refreshes every chart on the page. Layout (12-col grid): Row 0 : 6 KPI tiles (from #831), each 2 cols × 2 cells Row 2-5: calls-daily | calls-hourly (6 + 6 cols × 4 cells) Row 6-9: jobs-daily | jobs-hourly (6 + 6 cols × 4 cells) Row 10+: sync-daily | sync-hourly (6 + 6 cols × 4 cells) Until nc-vue#323 ships a new @conduction/nextcloud-vue beta release, the chart widgets that need the `bucket` shorthand will fall back to the "unavailable" empty state (per the nc-vue PR design — no partial queries fired against null ranges). KPI tiles render normally. * chore(deps): bump @conduction/nextcloud-vue ^1.0.0-beta.67 → ^1.0.0-beta.68 Picks up the dashboard date-range header + CnChartWidget.dataSource.bucket shorthand from ConductionNL/nextcloud-vue#326 (auto-published by semantic-release on merge into beta). With this bump, the 6 chart widgets in src/manifest.json's Dashboard page configuration (see #838) leave the "unavailable" fallback state and actually fire OR groupBy queries: GraphQL query($from: String!, $to: String!) { call_log(groupBy: { field: \"created\", interval: DAY, from: \$from, to: \$to }) { groups { key value } } } Variables resolve from the CnDashboardPage's `dateRange` inject, which the manifest enables via `dateRange: { enabled: true, persistKey: \"openconnector-dashboard\" }`. End-to-end pipeline unblocked: openregister#1611 (groupBy primitive, opsx-shipped) → nextcloud-vue#326 (consumer-side bucket + date-range, merged into beta) → this dependency bump → #838's chart widgets render. devDependencies in package.json got alphabetically reordered by npm during the install — content-equal to before the bump, just re-sorted to match npm's preferred ordering.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
OpenRegister has shipped (or is shipping in #1611) an ad-hoc
groupBy: GroupByInputargument on every auto-generated GraphQL list query, returninggroups: [GroupBucket!]with{ key, value }entries. To consume that contract from the dashboard fleet, this lib needs:CnDashboardPageso every chart on a page tracks the same range;bucketshorthand on the chart widget'sdataSourceblock so manifest authors get time-bucketed series without writing custom GraphQL.Both ship here, fully backwards-compatible.
What's new
CnDashboardPage.dateRangeprop (defaultnull) — whenenabled: true, renders aCnDateRangePickerbetween the header and the grid, persists tolocalStorage(whenpersistKey), emits@date-range-change, AND providescnDashboardDateRange(a Vue ref) to every descendant widget. When omitted, the dashboard is byte-identical to before.CnDateRangePicker— new public component. TwoNcDateTimePickers + a presetNcSelectbehind a single v-model. Exports the canonicalDEFAULT_DATE_RANGE_PRESETSlist (today / last-7 / last-30 / last-90 / custom) plus a pureresolvePresetWindow(presetId, presets, now?)helper so consumers and the dashboard share one source of truth.useDataSource.bucketshorthand — emits OR'sgroupByargument and resolves to{ series, categories }. Client-side validation ofinterval(case-insensitive against theTimeIntervalenum) andmetric(againstAggregationMetric); throws cleanly whenmetric != countandmetricFieldis missing, instead of firing a half-formed request. ExportsbuildBucketQueryfor direct use.CnChartWidgetconsumes the inject — whendataSource.bucketis set, the widget readscnDashboardDateRangeand uses its{from, to}for the GraphQL variables. Falls back tobucket.staticRangewhen no dashboard ancestor is present. If neither resolves, no query is fired and the chart shows its fallback / unavailable state.Backwards compatibility
default— no manifest change is required for existing dashboards.CnChartWidgetmounted outside a dashboard (Storybook, jest with shallowMount, isolated detail pages) injects a defaultref(null)factory, so existing tests/usages keep working.useDataSource's newrangeoption is optional; the existingaggregate: 'count'and rawgraphql:branches are unchanged.cnDashboardDateRangeprovide is installed unconditionally so descendants caninject(key, ref(null))without a fallback dance —ref.value === nullwhen the feature is off.Drive-by fixes
These two ride along because they were blocking the work:
fix(CnTreeView):@type {Array<*>}is rejected by vue-docgen-cli's expression parser, which aborts the wholeprebuild:docsrun onbeta. The pre-commit hook regenerates docgen partials on every Cn* SFC change, so this one line was blocking every other contributor from committing a Cn* edit. Also commits 16 backfilleddocs/components/_generated/Cn*.mdpartials that had been blocked behind the same parse failure.build(eslint): Afternpm ci,build:validatorswrites a 100KB+ minified single-line bundle intosrc/utils/validateManifestV2.compiled.js. The file is gitignored, but eslint's flat config doesn't honor.gitignore— fullnpm run lintwas reporting 15K stylistic errors against minified output. Added to the eslintignoreslist explicitly.Spec
openspec/changes/add-dashboard-date-range-and-chart-bucket/proposal.md(+ design + 2 specs + tasks).openregister/openspec/changes/add-time-bucket-aggregation/specs/graphql-api/spec.md.Test plan
CI runs the rest; locally verified:
npm run lint— 0 errors (447 pre-existing warnings).npm test— every new spec passes (CnDateRangePicker,CnDashboardPageDateRange,useDataSourcebucket cases,useGraphQLselector pinning,CnDashboardPagedispatcher untouched). Pre-existing failures onbeta(validateManifest.wikiStabilise,validateManifest.detailSidebarTabs,CnSearchPage,CnDataMatrix) are unrelated — verified bygit stash+ re-running on a clean checkout.npm run check:docs— every new public export (CnDateRangePicker,DEFAULT_DATE_RANGE_PRESETS,resolvePresetWindow,buildBucketQuery) has a doc page; every new prop / event / provide is mentioned. Pre-existing prop-coverage gaps onCnWidget*components are unrelated.cd docusaurus && npm run prebuild:docs— now runs clean (was broken onbetadue to the CnTreeView parse error fixed here).Follow-ups
None blocking. Open questions resolved in the proposal:
dateRange.default:last-7(resolves tofrom = now − 7d (00:00 UTC),to = now (23:59 UTC)).selectByPathextraction: kept inuseGraphQL.js— the[].fieldflat-map syntax already supported the OR contract; a focused test pins it.