We’re trying to work through field visibility for users in the reporting tab. I believe there are 2 toggles, and 4 different places to potentially pull in a field when building a report. To the best of our knowledge, this is how we believe the toggles interact with whether a field is visible in those 4 places. Can holistics validate this?
Toggle: Hidden in model
Toggle: Listed in Dataset “view” property
Visible in Custom Dataset View
Visible on Original Dataset View
Visible in “Add Field” Drop Down
Visible in AQL
True
True
True
False
False
True
True
False
False
False
False
True
False
True
True
True
True
True
False
False
False
True
True
True
If this is accurate, we've got a few different questions:
We want to ensure that some fields are inaccessible to analyst users when building reports (our data team have admin roles), but it seems like no matter what toggles we set, the fields are always accessible via AQL. Is there any way to prevent this?
We want some way for admins to access fields when building reports that are both hidden AND not included in the dataset, but not making those fields available to general users with the analyst role (in looker, we were able to go into develop mode, and build / edit a report while on that branch, so we could temporarily toggle hidden for ourselves without exposing those fields to general users). Is there a way to do this in holistics?
Having a different set of fields accessible on the custom dataset view and the “Add Field” drop-down has caused a decent amount of confusion at times. Is there any way to bring those in line? ex.
A field is hidden in the model but pulled into the dataset. Examples of when this is needed:
we’re using this when one single model is used in multiple datasets, and a given field should be available for use in one dataset but not another
we’re also using this in cases of extending a model (overriding the “hidden” parameter would mean that the entire field would need to be redefined, which is a LOT of duplicate code in certain cases where we have 4 extensions of the same model, plus the original model)
A field is not hidden in the model and not pulled into the dataset. We initially ran into this quite a bit and it was causing quite a bit of confusion for our internal users, but we’ve mitigated this by hiding fields that would run into this.
Thank you for your questions. And great description of your use cases there!
Yes your table is correct. Here’re the mechanisms which produce the behaviors listed in your table:
Toggle “hide field in model” will hide it entirely from the dataset. Thus it won’t be visible in the “Add Field” dropdown" either.
The purpose of Custom Dataset View (the “view” property) is to customize the view of the field list only. It doesn’t have any function to hide a field. Another note is that, if you “hide a field in model”, but still list it in the dataset “view”, it’ll overwrite the “hide field in model”.
A field can still be accessed via AQL even though it has been hidden in model.
Regarding your questions, please find our answers below:
We want to ensure that some fields are inaccessible to analyst users when building reports (our data team have admin roles), but it seems like no matter what toggles we set, the fields are always accessible via AQL. Is there any way to prevent this?
As stated in rule #3 above, our current mechanism makes a field always accessible via AQL. Your use case is indeed valid and we’ve added in our backlog.
We want some way for admins to access fields when building reports that are both hidden AND not included in the dataset, but not making those fields available to general users with the analyst role (in looker, we were able to go into develop mode, and build / edit a report while on that branch, so we could temporarily toggle hidden for ourselves without exposing those fields to general users). Is there a way to do this in holistics?
We understand that you want to hide fields in dataset so that your analysts cannot access them at all, but your admin can still access them when building reports, is that correct?
The only workaround we can think of at the moment is to hide fields in model and your admins use AQL to reference the hidden fields if necessary. This can help restrict your analysts from accessing them via “Add Field” dropdown, but beware that they can still access them via AQL.
Again this’s another valid use case. We’ll look into a solution for it soon.
Having a different set of fields accessible on the custom dataset view and the “Add Field” drop-down has caused a decent amount of confusion at times. Is there any way to bring those in line? ex.
This is about the UX of our Dataset View feature. We second the confusion you listed there. We’ve added it in our backlog for future improvements as well.
How critical and urgent is each of the request to you? That’d help us prioritize our backlog better.
None of them are absolutely urgent, but would definitely be helpful to prevent confusion and misuse of some complex fields. I would say the following for importance:
Hiding fields from AQL: medium/high
Some way for technical users to access hidden fields more easily: low/medium
As you said, we can use AQL for now, though we won’t be able to if fields are hidden from AQL as well as requested in the previous bullet
Having the fields match in the custom dataset view and the drop-down: low
May I follow up a bit more on your use cases. When you say you want to hide a field from AQL and/or from the “add field” dropdown, which in the following is the main purpose?
(1) restricting the users from accessing that field, i.e. because it contain sensitive data.
(2) hiding it from users so that they don’t get confused or overwhelmed because that field is complicated or not important to them.
More of the second option. There are certain fields that the data team has added that should only be used in VERY restricted ways. ex. a field is incorrect unless it’s at a specific granularity and has certain filters, or a field could very easily be misinterpreted. We’re concerned that the fields could be easily misused and misunderstood by non-technical team members, so we want to hide the fields. Appreciate the help!
Your inputs will help us design the solution better.