GitHub user elnagne added a comment to the discussion: Table chart conditional formatting based on datetime columns and multi-column conditions
Hi everyone! @rusackas , our team at the University of Toronto is interested in contributing improvements to table chart conditional formatting based on [discussion #43646](https://github.com/apache/superset/discussions/43646). We’re looking at datetime conditions and combining conditions across multiple columns within one formatting rule. For datetime support, [@plaes’s existing implementation](https://github.com/plaes/superset/tree/feat/table-temporal-conditional-formatting) looks like a useful starting point. It adds datetime-specific inputs to the existing formatting UI, including absolute dates and relative-to-now offsets, and converts dates into timestamps to reuse the existing comparison logic. We’d like to coordinate with @plaes about building on this work, preserving attribution and addressing remaining integration issues. For multiple-column conditions, our understanding is that each formatting rule currently checks one source column. Multiple rules evaluate independently, and later matching rules can overwrite earlier formatting when they affect the same cell and styling property. We’d like to support cases such as: required_date < NOW() + 14 days AND status = 'Unordered' → color the entire row red, keeping all other rows visible For an initial POC, we propose allowing one optional additional condition within the same rule, joined with AND or OR. Our proposed UI changes include: - An “Add condition” button within the existing formatting popup. - An AND/OR selector and a second set of column, operator, and value inputs. - Inputs appropriate to each condition’s column type, including datetime controls. - One shared color and formatting target for the combined rule. - The ability to remove the second condition and return to a single-condition rule. For the implementation, both conditions would evaluate against values from the same returned row, without additional database queries. AND would require both conditions to match; OR would require at least one. Only then would the rule apply its style to the selected target column’s cell or the entire row. This would extend the saved rule configuration and give the evaluator access to the relevant row values. Existing single-condition rules would retain their behavior, and precedence between separate formatting rules would remain unchanged. Does this match the intended use case? We’d appreciate feedback on the scope and UI approach, and whether there’s related work we should coordinate with. GitHub link: https://github.com/apache/superset/discussions/43646#discussioncomment-19225876 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
