Project Hierarchy
Working with Linked Projects
Projects can be linked to each other in a hierarchical structure to allow the re-use of documentation common in multiple products.
The standard scenario is to create documentation for components (in Module Projects) and refer to the documentation in these components through traces from a Master Project (that represents a Product or System) to one or more Module Projects.
Accessing Linked Project Items
When a Master Project is opened, all linked projects are automatically loaded as well. The Project Explorer displays the Document Object books of the Master Project.
To display the Project Explorer of a linked project, use the Current Project Project selector dropdown in the Project Explorer.
To access the File Explorer of a linked project, select the corresponding project name under the File Explorer.
To link a Master Project to a Module Project, select Add/Remove button to select the project you want to link to.
Note! It is not possible to create circular linked-project structures.
The hierarchy of linked projects can be of arbitrary depth. The project linking hierarchy is displayed when clicking Project Hierarchy in the Navigation Bar.
Note! To access a Master Project and its Module Projects, you have to use credentials for the project in question. If the credentials in the sub-project are identical to those in the master project, you will be automatically logged in.
It is possible to create traces from the Master Project to your Linked projects (e.g.: You can trace a requirement in Product 1 to a specification in sub-module A.) and vice versa.
Note! Traces from master projects to sub-projects are not automatically updated to the latest state when a linked item is updated.
Consequently, you have to manually update traces (in the Trace Explorer, see below) to these document objects every time the document objects in the sub-project changes.
The Project Settings contains an option to configure the system to automatically update the traces between linked projects (Project Settings).
A trace between linked projects that are not of the latest revision is called an Obsolete Trace. Updating a child item in a linked trace relationship, causes this state as the trace from parent to child are per default not automatically updated. The child item is depicted with the Obsolete Trace icon in the Trace Explorer.
The Trace Explorer provides the function Trace to the latest revisions. Linked projects are ignorant of the traces from the master project. Traces from the master project will not appear in linked projects when the linked project is opened separately. This also applies to traces from linked projects to their master project.
To unlink a project, select the Add/Remove button for the project to unlink and click Save to store the new state.
Note! Traces from a master project to any unlinked projects still exist but are not displayed after the project has been unlinked.
Copy Project
To copy a project, select a Copy Project in the Actions dropdown.
Note! When copying a project, the following applies:
Only the most current revisions of the document objects are copied. No previous revisions are copied.
The project history is NOT copied.
Document Object locks are NOT copied
Test Runs are not copied but the Test Cases and Executed Test Cases are copied including their internal traces.
Signatures are not copied.
Give the copied project a new name.
Note! The new name must not be the same as an existing project name (case-insensitive)!
Finally, click OK to initiate the copy operation. Wait for the confirmation message that indicates the success of the operation.
Since the source project will be temporarily unavailable for other users during the copying operation, make sure affected users are notified before the copy action is initiated so they can log off in due time!
All objects in the created copied project will be internally updated to reflect the new name, including objects in Word Documents.
Note! Copying in linked projects: If the project to be copied is a project in a linked project structure with items in other projects tracing to items in the project to be copied, these incoming traces from document objects in other projects will not be automatically copied and tracing to the resulting project. These traces need to be recreated manually!!
Note! Backlinks in External Issues: if the project contains document object that trace to items in external systems (such as Jira, GitHub, Azure DevOps etc.), these traces will be recreated in the project BUT if the external items contain fields for backlink information to Aligned Elements Document Objects, these backlinks in the external items are not updated to reflect that items in the resulting project now also point to these external items!
Branching and Merging Projects
Branching
Aligned Elements projects can be branched in order to create an independent line of the documentation.
When triggering a branch from the Action dropdown menu, a new Aligned Elements Project will be created. The user must select the types of Document Objects that shall be copied from the origin to the branch project. The branch project will then contain the latest revisions of Document Objects of the selected Document Object types.
At branching, Project History events are added to both the origin and the branch projects to record the branch action. The branch project will indicate the name of the origin project in the lower left corner of the application.
Note that the following restrictions apply when branching a project. The branch project will not contain the following elements form the origin project:
Test Runs
Signatures
Snapshots
Old Revisions of Document Objects
Merging
When merging a branch back to the origin project, Document Object changes in the branch are added to the origin. If any conflicts exist between changes in the origin and the branch, they will be displayed to you and you can decide which version to use; i.e., the origin change or the branch change.
Note that the following elements are not merged back to the origin:
Test Runs
Signatures
Trace Tables
Queries
Charts
Tags
Locked Document Objects
Snapshots
Reviews
Users and User Groups
Template Paths – The Template path for the original and the branch project must be exactly the same at the time of merge.
Users – The users in both the original and branch project must be the same at the time of merge.
Note that the branch project still exists after merging. Although it is possible to continue working on the branch and merge additional changes back to the origin, only changes after the last merge occasion will be considered during a subsequent merge.
Note! At merge, the locking status of Document Objects in the target project are ignored i.e. when applicable locked objects are going to be overwritten by data from branched project during th emerge project. Therefore, it is best practice to make sure that no-one is working in to the target project when the merge action takes place.
Last updated
