Cross-tenant release settings let you configure basic settings for cross-tenant release packages and validation settings for the release workflow. This topic describes the configuration process.
Prerequisites
Before you start a cross-tenant release, you must use a super administrator or system administrator account in your environment to configure users for the cross-tenant release. For more information, see Add, configure, and manage Dataphin members.
ImportantWe recommend granting both development and operations permissions to users authorized for cross-tenant releases.
In the source environment, use a system administrator account to initiate maintenance for the cross-tenant release and enter maintenance mode. For more information, see Maintain/Upgrade Dataphin.
Limitations
Automatic permission granting supports only table-level permissions, not column-level permissions. If a released task lacks permissions for certain columns and automatic permission granting is enabled, the system grants the production account table-level permissions.
Automatically granted permissions are not automatically revoked if a release fails. If you enable this option, permissions granted during a failed release are not rolled back. To revoke them, go to Management Center > Permission Management > Permission Management and revoke them manually.
When you perform a cross-tenant release of label views and label object tags, the system displays no permission validation error. This means the release can succeed even without the necessary permissions. After the release, instances of views and tags that lack permissions will fail. You must manually request permissions for the dependent objects.
When you release label views and label object tags across tenants, the system does not validate the permissions of the current operator. The operator only needs cross-tenant release permissions.
Permissions
Super administrators and system administrators can configure cross-tenant release settings.
Usage notes
Cross-tenant release settings vary between environments. The source environment focuses on basic settings for the release package, while the destination environment focuses on release validation settings.
In the source environment, you can configure the retention period, release credential, and external storage information for the release package. These settings can be modified in the destination environment. The release credentials in the source and destination environments must match to import a release file.
Settings for functional permission validation, data permission validation, and workflows in the destination environment directly affect the validation of a release package.
To improve release efficiency, you can ignore functional permission validation, ignore personal permission validation, and automatically grant permissions to the production account. For security purposes, assign the cross-tenant release user role with caution.
Procedure
Log on to Dataphin as a user authorized for cross-tenant releases.
In the top navigation bar on the Dataphin homepage, select Management Center > Cross-tenant Release.
On the Cross-tenant release settings page, configure basic settings, functional permission validation, data permission validation, and workflow settings.
Parameter
Description
Basic settings
Release file retention period
To control storage and compute costs, Dataphin allows you to set a retention period for cross-tenant release packages. The default is 180 days.
After the retention period expires, the system automatically deletes the release files to free up resources.
Cross-tenant release credential
A cross-tenant release credential acts as a password for cross-tenant releases. The release credentials in the source and destination environments must match to import a release file.
After generating a release credential in the source environment, copy it to the destination environment to ensure they are identical.
Allow download of release files
Yes: Default option. After a release file is exported, you can download it to your local machine.
No: After a release file is exported, you cannot download it to your local machine.
NoteDisallowing downloads reduces the risk of file leaks.
External storage settings for release files
OSS storage
By default, OSS storage is disabled. If you enable it, you must configure external OSS storage for your release files.
Using OSS storage to transfer release files between environments prevents inconsistencies from manual downloads and uploads. When you export a release file, it is automatically saved to OSS. You can then import the file directly from OSS by configuring the same OSS address in the destination environment.
Display name
The default value is OSS. You can enter up to 128 characters of any type, including spaces and special characters.
Endpoint
The endpoint for your OSS service's region. OSS endpoints are region-specific, and each region requires a unique domain name for access. For more information, see Access domain names (endpoints).
Bucket
The name of the bucket in your OSS service's region. A bucket is a container for storing objects. You can find the required bucket on the Bucket list page.
CNAME (optional)
You can enter a custom domain name for OSS.
AccessKey ID, AccessKey Secret
The AccessKey ID and AccessKey Secret for your OSS account. To learn how to obtain them, see Create an AccessKey.
Path (optional)
The storage path for release files in OSS.
NoteIf left empty, files are stored in the bucket's root directory. If the directory does not exist, the system creates it automatically during file import.
Functional permission validation
Release validation
Specifies whether to validate the operator's permissions to create, edit, and delete objects during a cross-tenant release. You can select Validate operator permissions or Ignore permission validation.
Validate operator permissions: During the import process, the system validates the operator's permissions in the current environment. If the operator lacks the required permissions, the system blocks the release.
NoteThe operator needs both cross-tenant release permissions and the standard permissions required for in-tenant releases and operations.
If the directory permission feature is enabled, this check also verifies that the publisher has view permissions for the destination task's directory. If not, the release fails.
Ignore permission validation: During the import process, the system bypasses validation of the operator's permissions.
NoteThe operator only needs cross-tenant release permissions.
Data permission validation - Development
Dev-Prod development project
Specifies whether to validate personal permissions when submitting a Dev-Prod development project during a cross-tenant release. You can select Ignore personal permissions on submission or Validate personal permissions.
Ignore personal permissions on submission: When submitting a Dev-Prod task, the system does not validate whether the operator has permissions for the data tables in the development project.
Validate personal permissions: When submitting a Dev-Prod task, the system validates whether the operator has permissions for the data tables in the development project.
Production project permissions
Specifies whether to validate release permissions for production projects during a cross-tenant release. You can select Validate production account permissions or Automatic granting.
Validate production account permissions: When releasing a production task, the system validates whether the production account has the required permissions for the production project.
Automatic granting: When releasing a production task, if the production account lacks the required permissions for the production project, the system automatically grants them.
Workflow settings - Architecture
Business object go-live approval
Defines the approval workflow for deploying business objects during a cross-tenant release. You can Ignore approval and release directly.
Workflow settings - Development
Release approval
Defines the release approval workflow for compute tasks, integration tasks, and table tasks during a cross-tenant release. You can Ignore approval and release directly.
Code review
Defines the review workflow for script tasks during a cross-tenant release. You can Ignore approval and release directly.
Workflow settings - Standards
ImportantThe data standards feature must be enabled.
New standard set approval
When a new standard set is released to the current environment, if approval is enabled in the standard set configuration, the release requires approval based on the standard review system template. You can click View approval template details to see the template.
If the standard set information is modified, the approval process follows the approval template settings of the current environment.
Standard release approval
Defines the approval policy for submitting a data standard for deployment or rollback during a cross-tenant release. You can select Ignore approval or Follow standard set configuration.
Ignore approval: When releasing in the current environment, the standard is deployed or rolled back directly without approval.
Follow standard set configuration: When submitting for deployment or rollback in the current environment, the approval process uses the settings from the standard set that contains the data standard.
Click Save to save the settings.
NoteTo reset the configuration page to its initial state, click Cancel.