You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the existing issues, and I could not find an existing issue for this feature
I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion
Describe the feature
Currently, each model can be configured to be part of a single group. While that's enough (and the correct configuration for most of the uses cases, there are some scenarios where allowing more than one configured group could be beneficial.
One scenario is having a group (e.g. data_utils) which contains internal models for the data engineering team that monitor in different ways models from other groups. Those models should be part of that data_utils group, but they can work today only with the public models from other groups.
By allowing multiple groups defined, we could still control in code the access to private models and unblock this (exceptional) use cases.
Describe alternatives you've considered
flag to ignore visibility restrictions running a dbt job (I don't like it as you lost control in the code of the visibility)
property in groups to elevate the permissions for a given group (still less granular control)
Who will this benefit?
DBT developers working in a single project configuration with multiple groups.
Are you interested in contributing this feature?
yes, although I'm not sure if I have the required skills for this.
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Is this your first time submitting a feature request?
Describe the feature
Currently, each model can be configured to be part of a single group. While that's enough (and the correct configuration for most of the uses cases, there are some scenarios where allowing more than one configured group could be beneficial.
One scenario is having a group (e.g. data_utils) which contains internal models for the data engineering team that monitor in different ways models from other groups. Those models should be part of that data_utils group, but they can work today only with the public models from other groups.
By allowing multiple groups defined, we could still control in code the access to private models and unblock this (exceptional) use cases.
Describe alternatives you've considered
Who will this benefit?
DBT developers working in a single project configuration with multiple groups.
Are you interested in contributing this feature?
yes, although I'm not sure if I have the required skills for this.
Anything else?
No response
The text was updated successfully, but these errors were encountered: