[Bug] Projects with `restrict-access: true` cannot leverage generic tests on private models about dbt-core HOT 1 OPEN

Thanks for opening @nicholasyager!

I agree that this is a bug. But I think it's slightly different from #8248, because generic tests can belong to groups, and dbt automatically sets their group attribute to match the model they're defined on.

The current intended behavior is:

1. If a model is installed via a "package" dependency, and restrict-access is False for that package, then it should be treated exactly the same as resources within this project. (This maintains historical behavior for packages.)
2. If a model is installed via a "package" dependency, and restrict-access is True, then the difference in namespace (package_name) should restrict private and protected references.
3. If a model is installed as a "project" dependency, then only reference to public models is allowed. To that end, the access level and namespace (package_name) are sufficient for resolving that reference, as groups don't currently exist across projects.

The current issue is that dbt's application of (2) is too broad, applying restrict-access even to resources within the same package/group. Rather than changing this logic to skip private reference checks for tests, I think we need to change this logic to be something like the following:

    def is_invalid_private_ref(
        ...
        return is_private_ref and (
            # Invalid reference because the group does not match
            (hasattr(node, "group") and node.group and node.group != target_model.group)
            # Or, invalid because these are different namespaces (project/package) and restrict-access is enforced
            or (node.package_name != target_model.package_name and restrict_package_access)
        )

When I try that change locally, and your reproduction case, dbt passes (and does not raise a DbtReferenceError).

Speaking of groups across projects...

Feature: Support cross-project Group evaluation

It sounds like you might be thinking in a direction similar to this proposal:

• #9340 (comment)

The idea there is, a model should be ref'able by specific other projects, based on some opt-in criteria shared by both. If we pursue that idea, it would make sense to add group (and whatever other necessary properties) to ModelNodeArgs (which I see came up in linked conversation).

Open to hearing your thoughts on #9340!

from dbt-core.