Merge branch 'current' into issue-4180

website/docs/docs/build/groups.md

@@ -19,7 +19,7 @@ This functionality is new in v1.5.
 
 ## About groups 
 
-A group is a collection of nodes within a dbt DAG. Groups are named, and every group has an `owner`. They enable intentional collaboration within and across teams by restricting [access to private](/reference/resource-properties/access) models.
+A group is a collection of nodes within a dbt DAG. Groups are named, and every group has an `owner`. They enable intentional collaboration within and across teams by restricting [access to private](/reference/resource-configs/access) models.
 
 Group members may include models, tests, seeds, snapshots, analyses, and metrics. (Not included: sources and exposures.) Each node may belong to only one group.
 
@@ -94,7 +94,7 @@ select ...
 
 ### Referencing a model in a group
 
-By default, all models within a group have the `protected` [access modifier](/reference/resource-properties/access). This means they can be referenced by downstream resources in _any_ group in the same project, using the [`ref`](/reference/dbt-jinja-functions/ref) function. If a grouped model's `access` property is set to `private`, only resources within its group can reference it. 
+By default, all models within a group have the `protected` [access modifier](/reference/resource-configs/access). This means they can be referenced by downstream resources in _any_ group in the same project, using the [`ref`](/reference/dbt-jinja-functions/ref) function. If a grouped model's `access` property is set to `private`, only resources within its group can reference it. 
 
 <File name='models/schema.yml'>
 

website/docs/docs/build/semantic-models.md

@@ -29,6 +29,7 @@ Semantic models have 6 components and this page explains the definitions with so
 | [Primary Entity](#primary-entity) | If a primary entity exists, this component is Optional. If the semantic model has no primary entity, then this property is required. | Optional |
 | [Dimensions](#dimensions) | Different ways to group or slice data for a metric, they can be `time` or `categorical` | Required |
 | [Measures](#measures) | Aggregations applied to columns in your data model. They can be the final metric or used as building blocks for more complex metrics | Optional |
+| Label | The display name for your semantic model `node`, `dimension`, `entity`, and/or `measures` | Optional |
 
 ## Semantic models components
 

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

@@ -25,7 +25,7 @@ The two concepts will be closely related, as we develop multi-project collaborat
 
 ## Related documentation
 * [`groups`](/docs/build/groups)
-* [`access`](/reference/resource-properties/access)
+* [`access`](/reference/resource-configs/access)
 
 ## Groups
 

website/docs/docs/deploy/deployment-overview.md

@@ -58,6 +58,12 @@ Learn how to use dbt Cloud's features to help your team ship timely and quality
     link="/docs/deploy/run-visibility"
     icon="dbt-bit"/>
 
+<Card
+    title="Retry jobs"
+    body="Rerun your errored jobs from start or the failure point."
+    link="/docs/deploy/retry-jobs"
+    icon="dbt-bit"/>
+
 <Card
     title="Job notifications"
     body="Receive email or Slack channel notifications when a job run succeeds, fails, or is canceled so you can respond quickly and begin remediation if necessary."

website/docs/docs/deploy/monitor-jobs.md

@@ -10,6 +10,7 @@ Monitor your dbt Cloud jobs to help identify improvement and set up alerts to pr
 This portion of our documentation will go over dbt Cloud's various capabilities that help you monitor your jobs and set up alerts to ensure seamless orchestration, including:
 
 - [Run visibility](/docs/deploy/run-visibility) — View your run history to help identify where improvements can be made to scheduled jobs.
+- [Retry jobs](/docs/deploy/retry-jobs) — Rerun your errored jobs from start or the failure point.
 - [Job notifications](/docs/deploy/job-notifications) — Receive email or slack notifications when a job run succeeds, fails, or is canceled.
 - [Webhooks](/docs/deploy/webhooks) — Use webhooks to send events about your dbt jobs' statuses to other systems.
 - [Leverage artifacts](/docs/deploy/artifacts) — dbt Cloud generates and saves artifacts for your project, which it uses to power features like creating docs for your project and reporting freshness of your sources.

website/docs/docs/deploy/retry-jobs.md

@@ -4,13 +4,13 @@ sidebar_label: "Retry jobs"
 description: "Rerun your errored jobs from start or the failure point."
 ---
 
-If your dbt job run completed with a status of `result:error` , you can rerun it from start or from the point of failure in dbt Cloud.
+If your dbt job run completed with a status of **Error**, you can rerun it from start or from the point of failure in dbt Cloud.
 
 ## Prerequisites
 
 - You have a [dbt Cloud account](https://www.getdbt.com/signup).
 - You must be using [dbt version](/docs/dbt-versions/upgrade-core-in-cloud) 1.6 or newer.
-- The most recent run of the job hasn't completed successfully. The latest status of the run is `error`.
+- The most recent run of the job hasn't completed successfully. The latest status of the run is **Error**.
     - The job command that failed in the run must be one that supports the [retry command](/reference/commands/retry).
 
 ## Rerun an errored job
@@ -26,7 +26,7 @@ If your dbt job run completed with a status of `result:error` , you can rerun it
 <Lightbox src="/img/docs/deploy/native-retry.gif" width="70%" title="Example of the Rerun options in dbt Cloud"/>
 
 ## Related content
-
+- [Retry a failed run for a job](/dbt-cloud/api-v2#/operations/Retry%20a%20failed%20run%20for%20a%20job) API endpoint
 - [Run visibility](/docs/deploy/run-visibility)
 - [Jobs](/docs/deploy/jobs)
 - [Job commands](/docs/deploy/job-commands)

website/docs/reference/model-properties.md

@@ -18,7 +18,7 @@ models:
       show: true | false
     [latest_version](/reference/resource-properties/latest_version): <version_identifier>
     [deprecation_date](/reference/resource-properties/deprecation_date): <YAML_DateTime>
-    [access](/reference/resource-properties/access): private | protected | public
+    [access](/reference/resource-configs/access): private | protected | public
     [config](/reference/resource-properties/config):
       [<model_config>](/reference/model-configs): <config_value>
     [constraints](/reference/resource-properties/constraints):
@@ -46,7 +46,7 @@ models:
         [description](/reference/resource-properties/description): <markdown_string>
         [docs](/reference/resource-configs/docs):
           show: true | false
-        [access](/reference/resource-properties/access): private | protected | public
+        [access](/reference/resource-configs/access): private | protected | public
         [constraints](/reference/resource-properties/constraints):
           - <constraint>
         [config](/reference/resource-properties/config):

website/docs/reference/node-selection/methods.md

@@ -321,7 +321,7 @@ Supported in v1.5 or newer.
 
 <VersionBlock firstVersion="1.5">
 
-The `access` method selects models based on their [access](/reference/resource-properties/access) property.
+The `access` method selects models based on their [access](/reference/resource-configs/access) property.
 
 ```bash
 dbt list --select access:public       # list all public models

website/docs/reference/resource-configs/access.md

@@ -0,0 +1,97 @@
+---
+resource_types: [models]
+datatype: access
+---
+
+<File name='models/<schema>.yml'>
+
+```yml
+version: 2
+
+models:
+  - name: model_name
+    access: private | protected | public
+```
+
+</File>
+
+<VersionBlock lastVersion="1.6">
+
+Access modifiers may be applied to models one-by-one in YAML properties. In v1.5 and v1.6, you are unable to configure `access` for multiple models at once. Upgrade to v1.7 for additional configuration options. A group or subfolder contains models with varying access levels, so when you designate a model with `access: public`, make sure you intend for this behavior.
+
+</VersionBlock>
+
+<VersionBlock firstVersion="1.7">
+
+You can apply access modifiers in config files, including `the dbt_project.yml`, or to models one-by-one in YAML properties. Applying access configs to a subfolder modifies the default for all models in that subfolder, so make sure you intend for this behavior. When setting individual model access, a group or subfolder might contain a variety of access levels, so when you designate a model with `access: public` make sure you intend for this behavior.
+
+There are multiple approaches to configuring access:
+
+In the model configs of `dbt_project.yml``: 
+
+```yaml
+models:
+  - name: my_public_model
+    access: public # Older method, still supported
+    
+```
+Or (but not both)
+
+```yaml
+models:
+  - name: my_public_model
+    config:
+      access: public # newly supported in v1.7
+    
+```
+
+In a subfolder: 
+```yaml
+models:
+  my_project_name:
+    subfolder_name:
+      +group: <my_group>
+      +access: private  # sets default for all models in this subfolder
+```
+
+In the model.sql file:
+
+```sql
+-- models/my_public_model.sql
+
+{{ config(access = "public") }}
+
+select ...
+```
+
+</VersionBlock>
+
+## Definition
+The access level of the model you are declaring properties for.
+
+Some models (not all) are designed to be referenced through the [ref](/reference/dbt-jinja-functions/ref) function across [groups](/docs/build/groups).
+
+| Access    | Referenceable by              |
+|-----------|-------------------------------|
+| private   | same group                    |
+| protected | same project/package          |
+| public    | any group, package or project |
+
+If you try to reference a model outside of its supported access, you will see an error:
+
+```shell
+dbt run -s marketing_model
+...
+dbt.exceptions.DbtReferenceError: Parsing Error
+  Node model.jaffle_shop.marketing_model attempted to reference node model.jaffle_shop.finance_model, 
+  which is not allowed because the referenced node is private to the finance group.
+```
+
+## Default
+
+By default, all models are "protected." This means that other models in the same project can reference them.
+
+## Related docs
+
+* [Model Access](/docs/collaborate/govern/model-access#groups)
+* [Group configuration](/reference/resource-configs/group)

website/docs/reference/resource-configs/contract.md

@@ -25,9 +25,9 @@ This is to ensure that the people querying your model downstream—both inside a
 
 The `data_type` defined in your YAML file must match a data type your data platform recognizes. dbt does not do any type aliasing itself. If your data platform recognizes both `int` and `integer` as corresponding to the same type, then they will return a match.
 
-When dbt is comparing data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. If you need a more-precise assertion, it's always possible to accomplish by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).
+When dbt compares data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. You can accomplish a more-precise assertion by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).
 
-That said, on certain data platforms, you will need to specify a varchar size or numeric scale if you do not want it to revert to the default. This is most relevant for the `numeric` type on Snowflake, which defaults to a precision of 38 and a scale of 0 (zero digits after the decimal, such as rounded to an integer). To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`.
+Note that you need to specify a varchar size or numeric scale, otherwise dbt relies on default values. For example, if a `numeric` type defaults to a precision of 38 and a scale of 0, then the numeric column stores 0 digits to the right of the decimal (it only stores whole numbers), which might cause it to fail contract enforcement. To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`. dbt Core 1.7 and higher provides a warning if you don't specify precision and scale when providing a numeric data type.
 
 ## Example
 
@@ -47,6 +47,8 @@ models:
           - type: not_null
       - name: customer_name
         data_type: string
+      - name: non_integer
+        data_type: numeric(38,3)
 ```
 
 </File>

website/sidebars.js

@@ -642,7 +642,6 @@ const sidebarSettings = {
           type: "category",
           label: "General properties",
           items: [
-            "reference/resource-properties/access",
             "reference/resource-properties/columns",
             "reference/resource-properties/config",
             "reference/resource-properties/constraints",
@@ -659,6 +658,7 @@ const sidebarSettings = {
           type: "category",
           label: "General configs",
           items: [
+            "reference/resource-configs/access",
             "reference/resource-configs/alias",
             "reference/resource-configs/database",
             "reference/resource-configs/enabled",

website/vercel.json

@@ -4001,6 +4001,11 @@
       "source": "/docs/dbt-cloud/on-premises/upgrading-kots",
       "destination": "/docs/deploy/single-tenant",
       "permanent": true
+    },
+    {
+      "source": "/reference/resource-properties/access",
+      "destination": "/reference/resource-configs/access",
+      "permanent": true
     }
   ]
 }