I. Relationship Between Projects and Executions

A project consists of one or more executions.

• Sprints/iterations are managed under executions. An execution lists all sprints/iterations that belong to the project.
• Executions help distribute workload from the project module by managing sprints/iterations separately.
• Execution team members can quickly open the execution task list from the Execution top-level navigation.
• Data under an execution—such as requirements, versions, test cases, bugs, test requests, test reports, team members, and whitelist users—is synchronized and displayed in the parent project. An execution can only be linked to products that are already linked to its parent project.
• Execution requirements are linked directly from the requirements under the associated product.

II. Access Control Relationship Between Projects and Executions

Project and execution permissions are maintained independently, but their access control settings are related:

• Having access to a project does not necessarily mean you can access all executions under that project.
• Having access to an execution does not necessarily mean you can access the project that the execution belongs to.
• If an execution’s access control is set to Inherit project access, users can access the execution only if they can access its parent project.
• If an execution’s access control is set to Private, only the execution team members and the project owner/stakeholders of the parent project can access it.

III. Data Relationships Between Projects and Executions

Some project data is synchronized from its executions:

• Requirements, versions, test cases, bugs, test requests, test reports, team members, and whitelist users under an execution are synchronized and displayed in the parent project.
• An execution can only be linked to products that are linked to its parent project.
• Execution requirements can be linked directly from requirements in the associated product.
• When removing a requirement from a project, if the requirement is already linked to an execution under the project, you must remove it from the execution first before it can be removed from the project.
• When removing a team member from a project, if the member also exists in an execution team under the project, the system prompts whether to remove the member from the execution team at the same time.
• Except for removing requirements and team members, removing or deleting other data affects only project-level data; execution-level data is not impacted.

Prompt shown when a project attempts to remove a requirement that is still linked to an execution:

图1

When removing a team member from a project, if the user is also a member of an execution team under the project, the system prompts whether to remove them as well:

• Click Confirm: removes the member from both the project team and the execution team.
• Click Cancel: removes the member only from the project team.

图2