New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text filters shown as input box in embed instead as dropdown #37914
Comments
There was already some research on linked filters by @WiNloSt which is good to have it here for reference: |
@albertoperdomo I might found 2 issues in this single issue.
|
I am reopening this one since I am testing to make sure the embedding behaves the same as metabase and I am getting a text filter everywhere so I cannot even test if linked filters are working as expected on embedding (i.e. similar to the metabase dashboard) Both when filters are set to Disabled or Locked |
Fixes: #37914 Previously, we removed locked parameters entirely. This is to prevent leaking potentially sensitive values. However, for the situation where the same field backs 1 locked or disabled paramter and 1 enabled parameter, we do still want to send the paramater values, because the enabled parameter implies that the values are permissible to see in the embed. So, this change will still remove parameters based on their 'disabled/locked/enabled' status, but will NOT remove the linked field ids if they're also being used by 'enabled' parameters. This results in the backend correctly sending necessary parameter values to the embed, where the frontend can then render the appropriate UI instead of falling back to just text filters.
Fixes: #37914 Previously, we removed locked parameters entirely. This is to prevent leaking potentially sensitive values. However, for the situation where the same field backs 1 locked or disabled paramter and 1 enabled parameter, we do still want to send the paramater values, because the enabled parameter implies that the values are permissible to see in the embed. So, this change will still remove parameters based on their 'disabled/locked/enabled' status, but will NOT remove the linked field ids if they're also being used by 'enabled' parameters. This results in the backend correctly sending necessary parameter values to the embed, where the frontend can then render the appropriate UI instead of falling back to just text filters.
* Keep Filter Values for enabled Parameters in Embedding Fixes: #37914 Previously, we removed locked parameters entirely. This is to prevent leaking potentially sensitive values. However, for the situation where the same field backs 1 locked or disabled paramter and 1 enabled parameter, we do still want to send the paramater values, because the enabled parameter implies that the values are permissible to see in the embed. So, this change will still remove parameters based on their 'disabled/locked/enabled' status, but will NOT remove the linked field ids if they're also being used by 'enabled' parameters. This results in the backend correctly sending necessary parameter values to the embed, where the frontend can then render the appropriate UI instead of falling back to just text filters. * test the case where a locked and enabled param share same field * Address feedback. Added comment to explain classify fn
* Keep Filter Values for enabled Parameters in Embedding Fixes: #37914 Previously, we removed locked parameters entirely. This is to prevent leaking potentially sensitive values. However, for the situation where the same field backs 1 locked or disabled paramter and 1 enabled parameter, we do still want to send the paramater values, because the enabled parameter implies that the values are permissible to see in the embed. So, this change will still remove parameters based on their 'disabled/locked/enabled' status, but will NOT remove the linked field ids if they're also being used by 'enabled' parameters. This results in the backend correctly sending necessary parameter values to the embed, where the frontend can then render the appropriate UI instead of falling back to just text filters. * test the case where a locked and enabled param share same field * Address feedback. Added comment to explain classify fn
* Keep Filter Values for enabled Parameters in Embedding Fixes: #37914 Previously, we removed locked parameters entirely. This is to prevent leaking potentially sensitive values. However, for the situation where the same field backs 1 locked or disabled paramter and 1 enabled parameter, we do still want to send the paramater values, because the enabled parameter implies that the values are permissible to see in the embed. So, this change will still remove parameters based on their 'disabled/locked/enabled' status, but will NOT remove the linked field ids if they're also being used by 'enabled' parameters. This results in the backend correctly sending necessary parameter values to the embed, where the frontend can then render the appropriate UI instead of falling back to just text filters. * test the case where a locked and enabled param share same field * Address feedback. Added comment to explain classify fn Co-authored-by: adam-james <21064735+adam-james-v@users.noreply.github.com>
* Keep Filter Values for enabled Parameters in Embedding Fixes: #37914 Previously, we removed locked parameters entirely. This is to prevent leaking potentially sensitive values. However, for the situation where the same field backs 1 locked or disabled paramter and 1 enabled parameter, we do still want to send the paramater values, because the enabled parameter implies that the values are permissible to see in the embed. So, this change will still remove parameters based on their 'disabled/locked/enabled' status, but will NOT remove the linked field ids if they're also being used by 'enabled' parameters. This results in the backend correctly sending necessary parameter values to the embed, where the frontend can then render the appropriate UI instead of falling back to just text filters. * test the case where a locked and enabled param share same field * Address feedback. Added comment to explain classify fn
Describe the bug
Decided to open this issue after spending some time reproducing #31347 and noticing the behavior has changed a lot.
Essentially, you expect filters to look the same in the embed, in the embed preview and in the dashboard inside of Metabase.
Findings:
The preview features and linking of the filters seems to work properly, unlike reported in #31347.
To Reproduce
Edit the dashboard, set the default value for text 1 as Doohickey -> Save
Go to Sharing -> Embed your application -> Preview
In the preview Text filter is still rendered as input box but text 1 is rendered as multi-select, in the embed it is a proper dropdown
Text:
Text 1 in preview inside of UI:
Text 1 opening iframe from preview URL in incognito mode:
Copy the iframe URL from the preview using inspect and open it in incognito mode. You will see that text and text1 are now rendered as dropdown and also that the linking of the filters is working as expected. Text2 is still rendered as input box.
Set text1 to locked, set a preview value for it as "Doohickey", publish, copy the iframe URL from the preview using inspect, open it in incognito mode. The results are properly filtered (Doohickey only), but text filter shows again as input box even though there is a default value
Expected behavior
The filters should look the same across dashboard in MB, embed preview and real life embed. The combination of setting a default value in the dashboard and setting the filter as editable triggers this consistent behavior but it should not be needed
Logs
No response
Information about your Metabase installation
Metabase v1.48.1
Severity
Might be blocking in certain use cases
Additional context
No response
The text was updated successfully, but these errors were encountered: