sadpandajoe commented on code in PR #42910:
URL: https://github.com/apache/superset/pull/42910#discussion_r4312259197
##########
superset-frontend/plugins/plugin-chart-echarts/src/BigNumber/BigNumberPeriodOverPeriod/transformProps.ts:
##########
@@ -225,6 +227,8 @@ export default function transformProps(chartProps:
ChartProps) {
compType,
comparisonColorEnabled,
comparisonColorScheme,
+ increaseColor,
Review Comment:
The new `increaseColor`/`decreaseColor` pass-through isn't covered by any
test: the helper tests and the `PopKPI` renders bypass `transformProps`, so
removing these two assignments (or mis-casing the snake_case form_data keys)
leaves everything green while picker changes stop reaching the chart. Could a
`transformProps` test pass `increase_color`/`decrease_color` through
`ChartProps` and assert the returned `increaseColor`/`decreaseColor`?
##########
superset-frontend/src/explore/components/controls/IntervalColorsControl/legacyColors.ts:
##########
@@ -0,0 +1,82 @@
+/**
+ * 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 {
+ getCategoricalSchemeRegistry,
+ validateNumber,
+} from '@superset-ui/core';
+
+export const parseIntervalBounds = (intervals?: string): number[] =>
+ (intervals ?? '')
+ .split(',')
+ .map(part => part.trim())
+ .filter(part => part !== '')
+ .map(Number)
+ .filter(bound => Number.isFinite(bound));
+
+/**
+ * Resolves the legacy `interval_color_indices` control (comma-separated,
+ * 1-indexed positions into the chosen categorical color scheme) into real
+ * hex colors, positionally matched to `bounds`. Shared by the control panel
+ * (display-only fallback while a legacy chart is being edited) and by
+ * `handleDeprecatedControls` (which migrates the value into `interval_colors`
+ * on load, since `interval_color_indices` is no longer a registered control
+ * and would otherwise be silently dropped on the next save).
+ */
+export const resolveLegacyIntervalColors = (
+ bounds: number[],
+ legacyIntervalColorIndices: string | undefined,
+ colorScheme: string | undefined,
+): string[] => {
+ // Non-strict lookup mirrors the Gauge renderer: an unregistered scheme
+ // falls back to the registry's default scheme.
+ const schemeColors =
+ getCategoricalSchemeRegistry().get(colorScheme)?.colors ?? [];
+ // Parse with the exact same semantics `getIntervalBoundsAndColors` in
+ // Gauge/transformProps.ts uses for this same legacy fallback (via
+ // `parseNumbersList`, not reimported here to avoid pulling the whole
+ // `@superset-ui/plugin-chart-echarts` package -- and every chart plugin it
+ // eagerly registers -- into `explore/store.ts`'s import graph): one
+ // unparseable (or blank) token discards every legacy index for the whole
+ // list, rather than resolving the other tokens independently. A more
+ // lenient parser here would let this one-time migration (and this
+ // display-only preview) disagree with how an untouched legacy chart has
+ // always rendered -- see #42910 review thread on this file.
+ let indices: number[];
+ try {
+ indices = (legacyIntervalColorIndices ?? '').split(',').map(part => {
+ if (validateNumber(part)) throw new Error('All values must be numeric');
+ return Number(part);
+ });
+ } catch {
+ indices = [];
+ }
+ // Bounds without an explicit legacy index keep their positional color,
+ // exactly as the Gauge renderer does (`colors[idx]`).
+ return bounds.map((_, index) => {
+ const legacyIndex = indices[index];
+ if (schemeColors.length === 0) return '';
+ if (Number.isFinite(legacyIndex)) {
+ return schemeColors[
+ (((legacyIndex - 1) % schemeColors.length) + schemeColors.length) %
Review Comment:
The positive-modulo normalization differs from the renderer for non-positive
legacy indices: `getIntervalBoundsAndColors` computes `colors[(ind - 1) % n]`,
which is `undefined` for index `0`, so that band falls back to `colors[idx]`.
With a 3-color scheme [A,B,C], bounds `20,60`, and indices `0,2`, the chart
renders [A,B] but this resolver shows [C,B], and editing only the second row
then persists C into the untouched first band. Should this keep the renderer's
fallback for indices below 1, with a parity test for `0,2`?
##########
superset/mcp_service/chart/preview_utils.py:
##########
@@ -1200,9 +1200,23 @@ def numeric_bound(field_name: str) -> float | None:
}
)
- colors = [
- _GAUGE_COLORS[(int(index) - 1) % len(_GAUGE_COLORS)] for index in
color_indices
- ] or list(_GAUGE_COLORS[: max(1, len(interval_bounds))])
+ explicit_colors = form_data.get("interval_colors")
Review Comment:
Explicit `interval_colors` only take precedence here, after the
`interval_color_indices` length check at line 1158 has already run. For a
legacy Gauge with `intervals: "30,60,100"`, a stale `interval_color_indices:
"1,2"` (kept in form_data after a bound was added), and three saved
`interval_colors`, Explore renders the three explicit colors but this preview
returns `InvalidGaugeFormData`. Could the legacy-index parsing/validation be
skipped when `interval_colors` is populated, and a test added with unparseable
or wrong-length indices alongside explicit colors?
--
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]
