sadpandajoe opened a new pull request, #44601:
URL: https://github.com/apache/superset/pull/44601
### SUMMARY
With Domain = Month and Subdomain = Week, cells in the calendar heatmap
collide:
one week's cell is drawn on top of another and its value becomes unreadable,
and
in some months a cell is drawn outside its block entirely.
No specific introducing change: the faulty logic arrived with the original
vendored cal-heatmap library in #356 (`feat: add calendar package and
storybook`) and has never been modified since, so this is upstream
cal-heatmap v3
behavior rather than a Superset regression.
Root cause is in `week.position.x` in the vendored library. A month block's
cell
list intentionally includes the week-start date borrowed from the *previous*
month (e.g. the May 2026 block begins with 2026-04-27, because that is the
week
containing May 1st). The old code positioned each cell with
`getWeekNumber(cell) - getWeekNumber(firstOfCellsOwnMonth) - 1`, which
measures
against the cell date's own calendar month instead of the month block being
rendered. For a borrowed cell those are different months, so:
- in most months the borrowed cell resolved to the same column as one of the
block's own cells (9 of 12 months in 2026 produced a duplicate position),
and
- when a month's 1st falls on the week-start day there is no borrowed cell
and
the first own cell resolved to `-1`, drawing it outside its block (June
2026).
The fix positions each cell by its index within the block's own generated
cell
list, which is the frame the cell list is actually built in, and drops the
now
unused `getMonthWeekNumber` helper. Because the cell index is the source of
truth, both position helpers now take the whole subdomain datum; `week`'s
`defaultColumnNumber` for month domains is also corrected to match the
inclusive
cell count `computeWeekSubDomainSize` actually generates, which previously
left
the block one column narrower than its own contents.
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Not captured: no running Superset instance was available in this environment.
The defect was confirmed statically and by reimplementing the exact d3 `%W`
week-number algorithm across all 12 months of 2026, cross-checked against the
SVG coordinates reported in #44532.
### TESTING INSTRUCTIONS
1. Create a Calendar Heatmap chart on any dataset with a temporal column and
a
metric.
2. Set **Domain** to `month` and **Subdomain** to `week`.
3. Choose a time range covering several months of 2026 (May and June 2026 are
the clearest cases) and run the query.
4. Each month block should show one cell per week, side by side, with no cell
overlapping another and no cell sitting outside or to the left of its
block.
Enable **Show Values** to confirm every week's value is legible.
5. Use the left/right browsing arrows to page across months and confirm the
layout stays correct on newly loaded blocks.
6. Re-check Domain = `year` with Subdomain = `week`, and Domain = `month`
with
Subdomain = `day`, to confirm the other combinations are unchanged.
### ADDITIONAL INFORMATION
- [x] Has associated issue: Fixes #44532
- [ ] Required feature flags:
- [x] Changes UI
- [ ] Includes DB Migration (follow approval process in SIP-59)
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
--
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]
