mikebridge commented on code in PR #41551: URL: https://github.com/apache/superset/pull/41551#discussion_r3691106235
########## superset-frontend/src/features/versionHistory/grouping.ts: ########## @@ -0,0 +1,276 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +import type { + ActivityRecord, + RelatedEntry, + SaveGroup, + TimelineEntry, +} from './types'; + +/** + * Stable identity for one activity record, used to deduplicate rows + * when merging pages (offset pagination can re-serve rows if a new + * save lands between page fetches). + */ +export function recordKey(record: ActivityRecord): string { + return [ + record.transaction_id, + record.entity_kind, + record.entity_uuid ?? record.entity_name, + record.source, + record.kind, + record.operation, + JSON.stringify(record.path), + // kind/operation/path can repeat within one transaction — the same field + // touched twice, or two entries under one collection path. Without the + // values, the second record is taken for a re-served copy of the first and + // dropped on page merge, so the timeline silently under-reports the save. + JSON.stringify(record.from_value ?? null), + JSON.stringify(record.to_value ?? null), + ].join('|'); +} + +/** Merge a newly fetched page into already loaded records, deduplicated. */ +export function mergeActivityPages( + existing: ActivityRecord[], + incoming: ActivityRecord[], +): ActivityRecord[] { + const seen = new Set(existing.map(recordKey)); + const merged = [...existing]; + incoming.forEach(record => { + const key = recordKey(record); + if (!seen.has(key)) { + seen.add(key); + merged.push(record); + } + }); + return merged; +} + +/** One related row per save of a related entity, regardless of how many + * change records that save produced. */ +export function relatedEntryKey(record: ActivityRecord): string { + return [ + record.transaction_id, + record.entity_kind, + record.entity_uuid ?? record.entity_name, + ].join('|'); Review Comment: Confirmed as a real edge, not fixable client-side: `entity_uuid` is null for tombstoned related entities, and two deleted entities sharing a name would collapse into one row. The client cannot do better with what the API sends — the record's natural identity (`entity_id`, `sequence`) is stripped by `apply_record_decoration` before serialization. Both capstone reviews flagged that stripping independently (the earlier panel's finding: "API removes the natural record identity, forcing the UI to hash mutable values"); this is another consequence of the same root cause. Tracked as a backend follow-up: expose the stable identity on the wire, then the name fallback here gets deleted. Until then the failure mode is bounded — same-named tombstones merging into one row, with all records retained and searchable inside it. _Triaged by Claude (AI) on behalf of @mikebridge._ ########## superset-frontend/src/features/versionHistory/canRestoreDashboard.ts: ########## @@ -0,0 +1,41 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +import type { RootState } from 'src/dashboard/types'; + +/** + * Whether the current user may restore a version of this dashboard. + * + * The dashboard counterpart of `canOverwriteSlice`, and it excludes + * externally managed dashboards for the same reason: their source of truth + * lives outside Superset, so a restore would be overwritten again by the next + * sync. + * + * Exported as one selector because the gate has more than one consumer — the + * history panel and the preview banner — and the header menu's own + * `is_managed_externally` check already showed how easily those drift apart. + * The panel is reachable directly via `?version_history=true`, so a gate + * applied only where the menu entry renders is not applied at all. The restore + * endpoint checks editorship but not external management, which leaves this as + * the only guard. + */ +export const selectCanRestoreDashboard = (state: RootState): boolean => + (state.dashboardInfo?.dash_edit_perm ?? false) && + !state.dashboardInfo?.is_managed_externally; Review Comment: Confirmed as a UX-parity gap, deliberately not fixed client-side in this PR — the data isn't there to fix it with. The chart side could honour `extra_editors` because `Slice.data` emits the field (`models/slice.py:270`); the dashboard payload has no `extra_editors` at all (`models/dashboard.py` — zero references), so no client predicate can consult it. And the gap is not specific to version history: `dash_edit_perm` comes from `canUserEditDashboard`, which gates the dashboard **Edit** affordance platform-wide with the same editors-only check — an extra-editor user already sees no Edit button anywhere. This gate is deliberately consistent with that existing platform behaviour, and fail-closed: the server permits the restore; the UI under-offers it. The right fix is backend-first — emit `extra_editors` on the dashboard payload as slices do, then widen the shared `canUserEditDashboard` so Edit, the history menu, and this gate all correct together. Recorded as a backend follow-up alongside the other payload additions. _Triaged by Claude (AI) on behalf of @mikebridge._ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
