Merge branch 'current' into dbeatty/saved-queries-example

website/docs/best-practices/how-we-mesh/mesh-4-faqs.md

@@ -44,9 +44,9 @@ You can use model versions to:
 
 A [model access modifier](/docs/collaborate/govern/model-access) in dbt determines if a model is accessible as an input to other dbt models and projects. It specifies where a model can be referenced using [the `ref` function](/reference/dbt-jinja-functions/ref). There are three types of access modifiers:
 
-1. **Private:** A model with a private access modifier is only referenceable by models within the same group. This is intended for models that are implementation details and are meant to be used only within a specific group of related models.
-2. **Protected:** Models with a protected access modifier can be referenced by any other model within the same dbt project or when the project is installed as a package. This is the default setting for all models, ensuring backward compatibility, especially when groups are assigned to an existing set of models.
-3. **Public:** A public model can be referenced across different groups, packages, or projects. This is suitable for stable and mature models that serve as interfaces for other teams or projects.
+* **Private:** A model with a private access modifier is only referenceable by models within the same group. This is intended for models that are implementation details and are meant to be used only within a specific group of related models.
+* **Protected:** Models with a protected access modifier can be referenced by any other model within the same dbt project or when the project is installed as a package. This is the default setting for all models, ensuring backward compatibility, especially when groups are assigned to an existing set of models.
+* **Public:** A public model can be referenced across different groups, packages, or projects. This is suitable for stable and mature models that serve as interfaces for other teams or projects.
 
 </detailsToggle>
 
@@ -208,12 +208,12 @@ First things first: access to underlying data is always defined and enforced by
 
 [Model access](/docs/collaborate/govern/model-access) defines where models can be referenced. It also informs the discoverability of those projects within dbt Explorer. Model `access` is defined in code, just like any other model configuration (`materialized`, `tags`, etc).
 
-**Public:** Models with `public` access can be referenced everywhere. These are the “data products” of your organization.
+* **Public:** Models with `public` access can be referenced everywhere. These are the “data products” of your organization.
 
-**Protected:** Models with `protected` access can only be referenced within the same project. This is the default level of model access. 
+* **Protected:** Models with `protected` access can only be referenced within the same project. This is the default level of model access. 
 We are discussing a future extension to `protected` models to allow for their reference in _specific_ downstream projects. Please read [the GitHub issue](https://github.com/dbt-labs/dbt-core/issues/9340), and upvote/comment if you’re interested in this use case.
 
-**Private:** Model `groups` enable more-granular control over where `private` models can be referenced. By defining a group, and configuring models to belong to that group, you can restrict other models (not in the same group) from referencing any `private` models the group contains. Groups also provide a standard mechanism for defining the `owner` of all resources it contains.
+* **Private:** Model `groups` enable more-granular control over where `private` models can be referenced. By defining a group, and configuring models to belong to that group, you can restrict other models (not in the same group) from referencing any `private` models the group contains. Groups also provide a standard mechanism for defining the `owner` of all resources it contains.
 
 Within dbt Explorer, `public` models are discoverable for every user in the dbt Cloud account — every public model is listed in the “multi-project” view. By contrast, `protected` and `private` models in a project are visible only to users who have access to that project (including read-only access).
 

website/docs/reference/dbt-jinja-functions/target.md

@@ -1,20 +1,18 @@
 ---
-title: "About target variable"
+title: "About target variables"
 sidebar_label: "target"
 id: "target"
-description: "Contains information about your connection to the warehouse."
+description: "The `target` variable contains information about your connection to the warehouse."
 ---
 
-`target` contains information about your connection to the warehouse.
+The `target` variable contains information about your connection to the warehouse.
 
-* **dbt Core:** These values are based on the target defined in your [`profiles.yml` file](/docs/core/connect-data-platform/profiles.yml)
-* **dbt Cloud Scheduler:**
-    * `target.name` is defined per job as described [here](/docs/build/custom-target-names).
-    * For all other attributes, the values are defined by the deployment connection. To check these values, click **Deploy** from the upper left and select **Environments**. Then, select the relevant deployment environment, and click **Settings**.
-* **dbt Cloud IDE:** The values are defined by your connection and credentials. To check any of these values, head to your account (via your profile image in the top right hand corner), and select the project under "Credentials".
+- **dbt Core:** These values are based on the target defined in your [profiles.yml](/docs/core/connect-data-platform/profiles.yml) file. Please note that for certain adapters, additional configuration steps may be required. Refer to the [set up page](/docs/core/connect-data-platform/about-core-connections) for your data platform.
+- **dbt Cloud** To learn more about setting up your adapter in dbt Cloud, refer to [About data platform connections](/docs/cloud/connect-data-platform/about-connections).
+   - **[dbt Cloud Scheduler](/docs/deploy/job-scheduler)**: `target.name` is defined per job as described in [Custom target names](/docs/build/custom-target-names). For other attributes, values are defined by the deployment connection. To check these values, click **Deploy** and select **Environments**. Then, select the relevant deployment environment, and click **Settings**.
+   - **[dbt Cloud IDE](/docs/cloud/dbt-cloud-ide/develop-in-the-cloud)**: These values are defined by your connection and credentials. To edit these values, click the gear icon in the top right, select **Profile settings**, and click **Credentials**. Select and edit a project to set up the credentials and target name.
 
-
-Some configs are shared between all adapters, while others are adapter-specific.
+Some configurations are shared between all adapters, while others are adapter-specific.
 
 ## Common
 | Variable | Example | Description |
@@ -54,6 +52,7 @@ Some configs are shared between all adapters, while others are adapter-specific.
 | `target.dataset` | dbt_alice | The dataset the active profile |
 
 ## Examples
+
 ### Use `target.name` to limit data in dev
 
 As long as you use sensible target names, you can perform conditional logic to limit data when working in dev.
@@ -68,6 +67,7 @@ where created_at >= dateadd('day', -3, current_date)
 ```
 
 ### Use `target.name` to change your source database
+
 If you have specific Snowflake databases configured for your dev/qa/prod environments,
 you can set up your sources to compile to different databases depending on your 
 environment. 

website/vercel.json

@@ -3847,11 +3847,6 @@
       "destination": "/dbt-cloud/api",
       "permanent": true
     },
-    {
-      "source": "/reference/data-test-configs",
-      "destination": "/reference/test-configs",
-      "permanent": true
-    },
     {
       "source": "/reference/declaring-properties",
       "destination": "/reference/configs-and-properties",