Looker 7 breaks merged dashboard filters

er1k
Participant V

Hey, not sure if others have seen the same issue, but with Looker 7 it seems that if you make any change to merged dashboard tile the dashboard removes filters from the current tile. Even if the change is smth really small like axis name change or any other change that is not related to the dashboard filter.

As some of the Looker developers have already done human errors on our instance with this behaviour then I want to ask how others are dealing with this issue and question to Looker guys, is it a bug or a feature?

Also if you recommend converting to lookml dashboards?

5 17 1,360
17 REPLIES 17

Scott_Schaen
Participant II

Oof! Glad you said something, I was just about to upgrade to 7 😮

I wouldn’t call this a “feature” per se, but it is currently expected behavior in the sense that we are aware of it and have included a warning Tooltip on the save popup.

From our documentation:

Any dashboard filters applied to a merged results tile will be turned off if the merged query is changed in any way. You can reinstate the filters by turning them back on again in the Add/Edit Dashboard Filters window.

This behavior exists as the result of a fix for a much more serious bug where filters could get applied incorrectly, so it’s a tricky case. I’ve raised this up internally and made sure your voice is heard—I’ll keep this updated!

Thanks for raising awareness, Erik 🙂

Kyle_Webb
Participant II

Yeah, we’ve experienced the same. Super frustrating when you are just wanting to change something small (e.g. change conditional formatting on a field) and then you have to redo 30+ filters. The fun bit is when you fix up all the filters, and then realised you forgot to do something, like change the name of a field, and then you get to do the filters all again.
@izzymiller thanks for sharing the context, I suppose it makes sense but definitely hope you guys can improve it soon!! It’s pretty frustrating and makes a simple change take ages (and more prone to error if you get the filter wrong).

Lior_Lavi
Participant I

same issue in our instance - any change in the merge results (also in the LookML) affect in the dashboard filter. this is very frustrating so hopefully Looker will fix this ASAP

Lior_Lavi
Participant I

Same issue in our Looker instance. very frustrating… )-:

Update:

Thank you for all of your feedback, especially the context around specific experiences— It really helps us understand and fix things.

I can say that we have opened, prioritized, and assigned this issue, and are committed to fixing it. I’m not yet 100% sure of a timeline but will share here with an estimate when I have one. Thanks again for your patience and feedback, I’ll keep this thread updated.

Lior_Lavi
Participant I

Hi @izzymiller,
Any update on this issue? what is the SLA?

This issue prevent us and our Looker users to make any changes in Merge Results tiles which have a major impact on the daily usage in Looker.

Please push tis high in the funnel and update us ASAP if possible

Thanks!
Lior

Lior,

Sorry for the delayed response. There’s currently no large update. We’ve prioritized and assigned the issue, and are aiming to have it resolved by May, possibly earlier. As always, I’m communicating your feedback back to the Product team.

I’ll make sure to keep this updated with any news.

Lior_Lavi
Participant I

Thanks for your replay @izzymiller!
Any update on this will be great

Lior

er1k
Participant V

After failing to turn off “Plot NULL values” for merged dashboard that merges 6 queries and has 5 filters, I needed to come back here and ventilate (after adding back 30 filters manually).

Please @izzymiller tell us that there are good news about the fix 🙏

There’s no update on this one yet-- My earlier info still stands, and I’'ll put up a new post here if anything changes. Appreciate all of your patience with this one while we get to the bottom of it and fix it.

Hello patient Lookers,

While this issue will not be 100% resolved in the 7.8 release (beginning deployment in 2wks), we’ve taken a great step in that direction:

In 7.8, changing the visualization config or the title of the tile will no longer clear the filters. We hope this reduces the frequency with which you run into this behavior, and that it’s easier to communicate to users that actually altering the query (adding fields, changing source queries) will cause filters to be removed.

We’re still committed to fixing this fully, this is just one step towards that.

Hey everyone! Great news. We’ve properly fixed this one. It will be available in 7.10, our next release —Estimated to begin shipping the week of June 15th.

As always, appreciate your reports, feedback, and patience 🙏

er1k
Participant V

Thanks for that!

Can you explain a bit on what caused this to last for so many months? Everything was working as expected before the Looker 7.0 update.

We haven’t done an official postmortem on this yet, and if there is one I’ll share info from it with the community. This is just my take on it.

Last year, an issue arose that caused dashboards containing merged tiles to throw a gnarly error on download/render. Fixing it temporarily just involved toggling the filters on and off, but regardless of the easy workaround this was an extremely impactful bug as it was preventing schedules/downloads for many customers.

After investigating, it became apparent that a “complete” fix would require a significant amount of work in complicated places— But we could create a very simple short-term fix by causing the filters to toggle off if the merge query changed in any way (basically automating part of the workaround).

We added the warning message that it would toggle off all filters to make sure users were aware, and shipped the change to fix the bug. In hindsight, we could have been more clear about the new behavior we’d introduced, or been more thoughtful about the the overall user experience we were creating.

Because we created this behavior intentionally as the result of fixing a highly impactful bug, we couldn’t simply roll-back the offending code, and were generally slower to prioritize as the line between “expected behavior” and “bug” had blurred somewhat. That’s another area we can strive to improve in the future.

Once we got this prioritized appropriately and slated for work, it still took a fair bit of time to accomplish because it was a significant chunk of coding— So significant that previously, we’d opted for the bandaid approach 😉.

Just want to add that all of your comments and context were absolutely key in getting this prioritized and ultimately fixed, so know that your voices were heard!

Top Labels in this Space
Top Solution Authors