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
When we implemented retention metadata support via default_table_workgroup_access, we introduced a gotcha where unless you specify the value of default_table_workgroup_access explicitly in a table's manually created workgroup_access, access to that table will be restricted to just the manual grants if there are deprecated tables in the same dataset.
80dc786 is an example of this: if there were deprecations in mozilla_org_derived, give the way our metadata generation currently works, workgroup:mozilla-confidential would have lost access to the table.
We should for non-deprecated tables automatically apply default_table_workgroup_access to the table-level metadata.yaml workgroup_access, and probably have a CI/lint check to warn against the redundant specification in both places once this is implemented.
When we implemented retention metadata support via
default_table_workgroup_access
, we introduced a gotcha where unless you specify the value ofdefault_table_workgroup_access
explicitly in a table's manually createdworkgroup_access
, access to that table will be restricted to just the manual grants if there are deprecated tables in the same dataset.80dc786 is an example of this: if there were deprecations in
mozilla_org_derived
, give the way our metadata generation currently works,workgroup:mozilla-confidential
would have lost access to the table.We should for non-deprecated tables automatically apply
default_table_workgroup_access
to the table-level metadata.yamlworkgroup_access
, and probably have a CI/lint check to warn against the redundant specification in both places once this is implemented.┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: