fix(insights): Retain the legend configuration inside the subscriptions as well

[vdekrijger]

Problem

With: #41836 we introduced a fix so that the show legend field was correctly being picked up when Insights were exported to PNGs. However post release, we found out that there are also requests to solve this for subscriptions (e.g.: #40630).

This PR therefore fixes it for both the PNG exports, and for the subscriptions.

Fixes: #40630

Changes

Subscriptions have their own path to generate the ExportAsset object which eventually will be rendered to be exported:

posthog/ee/tasks/subscriptions/subscription_utils.py

Lines 110 to 118 in 9f67611

	assets = [
	ExportedAsset(
	team=resource.team,
	export_format="image/png",
	insight=insight,
	dashboard=resource.dashboard,
	)
	for insight in insights[:max_asset_count]
	]

.

In order to avoid having multiple solutions (frontend extracting it from the display options, backend querying the DB), there is now 1 source of truth where the backend will fetch the "showLegend / show_legend" status of the Insight when sending it off to be rendered on the worker.

This means that this PR also cleans up a little bit of the frontend code introduced in the previous PR. This does however mean that a user must save their insight "Show Legend" option before the export will respect it, this is currently a little bit tricky as modifying the "Show Legend" button does not immediatly change the "Edit" -> "Save" button, however for the scope of this issue we will leave that behaviour as is. In order to work around this, users can first hit "Edit" -> "Change Show Legend" -> "Save". This is likely a path that they are familiar with as this hasn't changed.

How did you test this code?

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

1. Run the Posthog application locally
2. Create an insight (ensuring there is no legend)
3. Run the png export and confirm that there is no legend in the export
4. Adjust the display options, setting the Show Legend to true
5. Run the png export and confirm that this time, there is a legend on the export
6. Also ran an export of the dashboards to confirm it's all okay
7. Ran an export of the shared page for an insight with / without the show legend option enabled.
8. And finally ran a subscription test. I tried configuring an email with Twilio / mailgun but neither seemed to work for me, so I just retrieved the generated exported image from MinIO instead (see below).

With show_legend: false

Insight > export > png:

Share insight:

With show_legend: true

Insight > export > png:

Share insight:

Dashboard export:

Subscription export (fetched from MinIO):

Changelog: (features only) Is this feature complete?

N/A this is a small fix to an existing feature.

[github-actions]

Size Change: -173 B (-0.01%)

Total Size: 3.4 MB

ℹ️ View Unchanged

Filename	Size	Change
frontend/dist/toolbar.js	3.4 MB	-173 B (-0.01%)

_{compressed-size-action}

[greptile-apps]

_{5 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

logic: iterating through all source.values() and returning the first dict with showLegend is fragile - dict iteration order could cause it to pick up showLegend from an unexpected location if the schema changes

Suggested change

	for value in source.values():
	if isinstance(value, dict) and "showLegend" in value:
	return bool(value.get("showLegend", False))
	# Check specific filter fields that contain showLegend
	for filter_field in ['trendsFilter', 'lifecycleFilter', 'stickinessFilter']:
	if filter_field in source and isinstance(source[filter_field], dict):
	if 'showLegend' in source[filter_field]:
	return bool(source[filter_field].get('showLegend', False))

Prompt To Fix With AI

This is a comment left during a code review.
Path: posthog/models/insight.py
Line: 300:302

Comment:
**logic:** iterating through all `source.values()` and returning the first dict with `showLegend` is fragile - dict iteration order could cause it to pick up `showLegend` from an unexpected location if the schema changes

```suggestion
                # Check specific filter fields that contain showLegend
                for filter_field in ['trendsFilter', 'lifecycleFilter', 'stickinessFilter']:
                    if filter_field in source and isinstance(source[filter_field], dict):
                        if 'showLegend' in source[filter_field]:
                            return bool(source[filter_field].get('showLegend', False))
```

How can I resolve this? If you propose a fix, please make it concise.

[vdekrijger]

I prefer my implementation as the proposed one is quite brittle when we are adding new filters / have these hidden string dependencies.

In our current structure it is very unlikely that there are multiple showLegend flags, and if there will be, it will return the first one it encounters meaning that it won't break anything.

[greptile-apps]

Got it! Your current implementation is indeed more flexible and maintainable. I've noted your preference to avoid hardcoded filter field names when extracting configuration values from dynamic structures.

Here's a link to the new rule that will be applied in future reviews of similar patterns.