Email schedule purgatory when Show Filters is turned off

bug

(Scott Vickers) #1

We are wanting to add the ability to schedule and send emails from our embedded implementation as it is a heavily requested feature. Great we thought, we will just add the schedule_look_emails permission to our embed url and be done with it. Unfortunately we have run into a few problems and appear to have exhausted all the options with no workaround in sight.

The crux of the issue is that we have the Looker supplied filters turned off in all of our dashboards because we did a custom implementation to make the design match our app and improve the ux. example:

Because Show Filters is turned off, we discovered that the option to include selected filters is not present in the dialog to schedule an email.
Off:

On:

The consequence of this is that the email gets scheduled with the default values defined on the dashboard, and not the values that are currently rendered based on the user’s selection. This is confusing and not what would be expected. To make matters worse some of our dashboards can not have defaults defined because the default value is predicated on the locations that the user has access to via data security user attributes. In such cases the user will receive an email on schedule but it will just be an error message:
Error occurred while generating this dashboard - contact administrator (error: Render job 2ed43f6bd6b3a2d5ff23b635b1aed2d3[288] failed [Looker::Render::RendererNoRenderFinishedEventReceivedError])

Sooo… we gave up on being able to use the built-in Looker dialog and went the route of recreating the scheduling interface on our own and using the API to create the schedules…

Things were going well until we removed the schedule_look_emails permission from the embed URL. This was removed so that the Schedule option is not displayed in the gear dropdown of the embedded dashboard, since it doesn’t work as intended.

As is probably expected, now hitting the API with the current user was returning an auth error when submitting a schedule, because they don’t have permissions to create a schedule. In an attempt to circumvent this we changed the api call to run as a system account, but set the user id on the plan to the current logged in user so they are the owner and it will be executing under their security context.

var lookerUser = await getLookerUser(headsetUser); //get the current user
plan.DashboardFilters = plan.FiltersString; //set the filters
plan.UserId = lookerUser.Id; //set userId to current user
var createdPlan = await runAsAdminAsync(async () => await _looker.CreateScheduledPlanAsync(body:plan)); //execute api call as system account

Success! API call returned a 200, high fives all around. This was quickly followed by a moment of heartbreak when the email arrived:

The scheduled job “Executive Overview”[924] failed for . Please visit your content to view and resolve the error, or contact your Looker administrator if you need further assistance.

Error: User missing schedule_look_emails permission

Shit!

So I think we have exhausted all of our options and are back at square 1. Is it going to be impossible to get this implemented simply because we don’t want the filters to show up on the embedded dashboard?

Potential Looker Fixes:

  • Respect the filters applied to the current dashboard when scheduling, even if the user can’t see them in the interface
  • Decouple user permissions from UI settings when embedding. ie. The user can have schedule permissions, but another parameter can be used to hide the option from the gear menu.

Happy to hear any other suggestions to try if we have missed something.


(jeffrey.martinez) #2

Hey Scott!

Thanks for the detailed account, and the ingenious methodology. Seriously impressive. I believe my colleague Lauren had mentioned this in a recent report after a chat with you. I’m linking this submission to hers to add more complete detail of your use case to our product team. A request along the lines of capturing a schedule from an embed’s “present state” as well as possible further dividing the permissions per your proposed fix. Definitely worth a closer look!