General Looker administration
All your administration & self-hosting questions and content
- 490 Topics
- 1,221 Replies
We have a master set of dashboard and views which we need to push to 9 - 10 different data models. We are considering using a shell script and Jenkins to push updates across the data models. This will apply the model ‘client key’ to each of our updates. Does anyone have any experience or suggestions on updating multiple data models with the same views and dashboards and can make some suggestions? Thanks Regards Conor
Is there any way to do a find and replace on the view name? The Look validator provides some great find/replace functionality, but it seems to operate on fields, explores, and models only. It seems like views are the big missing one here. I tried using the field find/replace but only entering the view name to find/replace, and that didn’t work. I ended up doing each field one at a time.
I have a goal of having descriptions for all of our dimensions and measures, and having notes for all of our dashboard elements. To help reach that goal, I wrote this python script to calculate my ‘annotation coverage’ across my views and lookml dashboards. It requires two python packages - PyYAML and pandas. It takes one arg - the path to your lookml repo. Example usage: python looker_annotation_coverage.py ~/PycharmProjects/looker-q gist.github.com https://gist.github.com/DanielWeitzenfeld/f13bd8892dbe091eaa38 looker_annotation_coverage.py import os import sys import yaml import pandas as pd # Generates CSVs with aggregate stats about your LookML: # % of dimensions and measures that have descriptions # % of dashboard elements with a note This file has been truncated. show original
Git configuration in Looker has been updated in version 3.20 such that each user’s developer mode correlates with a branch (more here). With these changes, you can now introduce a Pull Request workflow for your Looker instance. Read more about integrating pull requests with Looker in Docs. If a developer has issued a pull request on Github, and you would like to revert those changes, there are a couple of options: If the pull request has not been merged Close the request without merging it. The developer should then Revert to Production to remove those changes from their dev mode. If the pull request has already been merged Revert this pull request in the Github UI. Merge the “revert” pull request that is created to remove the prior changes. With a webhook setup (as outlined here), production mode will be automatically updated with these changes. All developers should then pull these changes into their developer modes. They will be notified when they enter dev mode that there are ne
How to do code reviews for large developer teams? Important: This guide is only supported for self-hosted customers. Say you are hosting Looker on-prem. and have grown large enough that developer changes require code review before they are pushed to production, where business users see the changes. Here we will outline how you would go about setting up code reviews through a staging profile and branching. Our goal is to create a tree that has 2 auxiliary branches: “staging” and “dev”, and that allows us to review changes in the “staging” environment separately of the changes that happen in the “dev” environment. Example: Git set-up First, we need to create a new “dev” branch for our developer users: #ssh to self-hosted Looker instance cd <looker location>/looker/models-user-<user_id>/<model_name> #create a new branch git checkout -b dev # push the dev. branch to initiate it in a remote repo git push -u origin dev Where the <user_id> can be looked up under A
When you want to remove a user account from your Looker instance, my recommendation is to disable the user account instead of deleting the user. In Looker deleting a user account is a hard delete. Looker support has confirmed for me that this will alter historical usage reporting through the Admin > Usage page and the i__looker model. Instead, disable the user account by going to the edit page for a user, changing the top drop-down box to ‘disabled’, and clicking save.
###Use Case Imagine we have a customer facing campaign metrics dashboard, which is global for all customers. We also have access_filter_fields (doc here) set on campaigns.id so that our customers can only see their respective campaigns. The issue is that some of our customers have multiple campaigns, and that suggest_filters are disabled when access_filter_fields are used for security reasons. ###The Solution We will build a table into the dashboard which lists the available campaigns for the user’s set of model_access_filter values, and using the html: parameter, the user will be able to filter the dashboard on the desired campaign name by clicking on the value in the table. ###View LookML Let’s assume we are in the campaigns view, then we can use campaigns.id and campaigns.name to create a campaigns.name_with_link dimension. This dimension will utilize the html: parameter to create a link to the desired dashboard with an injected filter value of campaigns.id. - view: campaigns
Note: only users who have the appropriate permissions can create public URLs In order to share public URLs, public URL sharing must be enabled in your instance. This can be done in the Admin panel. Navigate to the Admin Panel. In the General tab, under Public Access, change the setting to Enabled. Hit Update. Public URL sharing is now enabled for your instance. You can generate a public URL from the Explore UI by pressing the Make Public button under the gear dropdown in the upper right. Or, you can edit a saved Look, check the Public Access box, and hit Save.
A full list of the behaviors for how the PDTs regenerate themselves: Whenever they hit their trigger they will regenerate. Whenever the SQL has changed either from being edited or pushed, the PDTs regenerate at the next query run. The PDTs associated with the query will all regenerate when selecting rebuild derived tables from the gear menu in Explore. Finally, we are working on a regenerate all PDTs feature, it is on our roadmap, in the meanwhile you could try dropping and recreating the looker_scratch schema as a workaround if it is easy to do. For more on PDTs, read our documentation here.
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.