Revisions

website/docs/docs/collaborate/govern/model-access.md

@@ -181,14 +181,20 @@ It is possible to `ref` a model from another project in two ways:
 
 See ["Project Dependencies"](project-dependencies) for an explanation of the advantages of each approach.
 
-If referencing a model from a package, you have the option of restricting `ref` access (or not) to protected models in that package. For historical reasons, to avoid breaking existing projects, the default behavior is that models in another project can `ref` both protected and public models in an installed package. This is useful for packages containing models for a common data source; you can install the package as source code, and run the models as if they were your own.
+#### How do I restrict access to models defined in a package?
 
-If you do wish to restrict `ref` access to _only_ public models in that package, you can set `enforce_access: True` in your package configuration:
+The maintainer of a project that can be installed as a package may choose whether to restrict other models' `ref` access to only its public models. The package maintainer does this by setting a `restrict_access` config to `True`. By default, the config is `False`, meaning that:
+- Models in the package with `access: protected` may be referenced by models in the root project, as if they were defined in the same project
+- Models in the package with `access: private` may be referenced by models in the root project, so long as they also have the same `group` config
+
+When `restrict_access: True`, any `ref` from outside the package to a protected or private model in that package will fail. Only models with `access: public` may be accessed outside the package.
+
+<File name="dbt_project.yml">
 
 ```yml
-packages:
-  - git: https://my-org/upstream-project
-    enforce_access: True  # default is False
+restrict_access: True
 ```
 
+</File>
+
 </VersionBlock>

website/docs/docs/collaborate/govern/project-dependencies.md

@@ -5,8 +5,8 @@ sidebar_label: "Project dependencies"
 description: "Reference public models across dbt projects"
 ---
 
-:::info
-Cross-project `ref` This is a feature of dbt Cloud Enterprise.
+:::info Cross-project `ref`
+This is a feature of dbt Cloud Enterprise.
 :::
 
 dbt Core v1.6 introduces a notion of `dependencies` between dbt projects. You're likely already familiar with installing other projects as [packages](/docs/build/packages), whereby you pull down another project's source code and treat it as your own.
@@ -27,4 +27,4 @@ The second is new. Unlike installing a package, the models in the `jaffle_financ
 
 Models referenced from a `project`-type dependency must use [two-argument `ref`](/reference/dbt-jinja-functions/ref#two-argument-variant), including the project name. Only public models can be accessed in this way.
 
-It's equally possible to install the `jaffle_finance` project as a `package` dependency. This will pull down its full source code., and require dbt to parse all its contents. dbt will expect you to configure and run those models as your own. This can be a useful pattern to achieve certain types of unified deployments in production. In development, it can add significant complexity and latency.
+It is equally possible to install the `jaffle_finance` project as a `package` dependency. This will pull down its full source code, and require dbt to parse all its contents. dbt will expect you to configure and run those models as your own. This can be a useful pattern to achieve certain types of unified deployments in production, or to make a coordinated change across multiple projects in development. It can add significant complexity and latency, however, when working within the narrower scope of a single project.

website/docs/guides/migration/versions/01-upgrading-to-v1.6.md

@@ -36,7 +36,7 @@ dbt Labs is committed to providing backward compatibility for all versions 1.x,
 
 [**Namespacing:**](/faqs/Models/unique-model-names) Model names can be duplicated across different namespaces (packages/projects), so long as they are unique within each package/project. We strongly encourage using [two-argument `ref`](/reference/dbt-jinja-functions/ref#two-argument-variant) when referencing a model from a different package/project.
 
-[**Project dependencies**](project-dependencies): Introduce `dependencies.yml`. Allow enforcing model access (public vs. protected/private) across project/package boundaries. Enable cross-project `ref` of public models, without requiring the installation of upstream source code, as a feature of dbt Cloud Enterprise.
+[**Project dependencies**](/docs/collaborate/govern/project-dependencies): Introduce `dependencies.yml`. Allow enforcing model access (public vs. protected/private) across project/package boundaries. Enable cross-project `ref` of public models, without requiring the installation of upstream source code, as a feature of dbt Cloud Enterprise.
 
 ### Quick hits
 

website/docs/reference/dbt_project.yml.md

@@ -83,6 +83,7 @@ vars:
   - macro_namespace: packagename
     search_order: [packagename]
 
+[restrict-access](/docs/collaborate/govern/model-access/how-do-i-restrict-access-to-models-defined-in-a-package): true | false
 ```
 
 </File>