Documentation
Data modeling
Publicity

Publicity of data model entities

The data model serves as a facade of your data and enables running queries via a rich set of APIs by referencing data model entities: cubes, views, and their members. Controlling whether they are public or not helps manage data access and expose a coherent representation of the data model to end users.

By default, all cubes, views, measures, dimensions, and segments are public, meaning that they can be used in API queries and they are visible during data model introspection.

Managing publicity

You can explicitly make a data model entity public or private by setting its public parameter to true or false. This parameter is available for cubes, views, measures, dimensions, and segments.

In development mode and in Playground, access control checks are disabled and all public parameters are ignored. It helps you conveniently debug the data model by using private data model entities in API queries and during data model introspection.

Dynamic data models

You can also control whether a data model entity should be public or private dynamically.

In the example below, the customers view would only be visible to a subset of tenants that have the team property set to marketing in the security context:

model/views/customers.yml
views:
  - name: customers
    public: "{{ is_accessible_by_team('marketing', COMPILE_CONTEXT) }}"
model/globals.py
from cube import TemplateContext
 
template = TemplateContext()
 
@template.function('is_accessible_by_team')
def is_accessible_by_team(team: str, ctx: dict) -> bool:
  return team == ctx['securityContext'].setdefault('team', 'default')

If you'd like to keep a data model entity public but prevent access to it anyway, you can use the query_rewrite configuration option for that.

Best practices

Cubes and views

If your data model contains both cubes and views, it's recommended to keep cubes private and only expose views to visualization tools. Doing so, you will have more control over queries that can be run against the data model.

Members

If you have measures or dimensions that are not intended to be exposed to end users, it's recommended to keep them private. Often, such auxiliary members would be used in calculated measures and dimensions.

YAML
JavaScript
cubes:
  - name: users
    sql_table: users
 
    dimensions:
      - name: first_name
        sql: first_name
        type: string
        public: false
 
      - name: initial
        sql: "LEFT({first_name}, 1)"
        type: string