Copy items to another workspace

You can copy or move items to another workspace within the same space.

Copy an item to another workspace

You can copy features, backlog items, manual tests, and Gherkin tests to another workspace within the same space. You can copy one item or test at a time. When copying a feature, all its child backlog items are also copied.

To copy an item to another workspace:

Prerequisites

You must have the following permissions:
- Copy to Different Workspace permission for the item type on both source and target workspaces.
- Create permission for the item type on the target workspace.
For details, see Permission categories and types.
Open the item that you want to copy.
In the item's Details tab, click More and select Copy to Different Workspace.
Choose the target workspace and click Copy.

After the copy completes, a message displays with a link to the new item in the target workspace.

Values and attributes of copied items

The new item is initiated as follows.

Field	Description
Phase	The phase is reset to New.
Comments	A comment is added containing a link to the original item in the source workspace.
Author	This is set to the user who performed the copy action.
Detected By	This field in defects is copied from the original item. Make sure that the same user exists in the target workspace.
History tab	The item is created with a clear History tab.

Field values and attributes are copied to the new item as follows.

Status	Details
Copied	The new item includes values for the fields that are defined at the shared space level. This applies to both system and custom fields. In addition, the following are copied: Attachments Backlog items: Tasks Features: Backlog items and tasks Tests: Data tables and sets, the current version
Not copied	Values are not copied where the value is defined at the workspace level, such as local application modules, programs, teams, and releases. In addition, the following are not copied: Comments, Data access categories Tests: Runs, previous versions, automation status

Status

Details

Copied

The new item includes values for the fields that are defined at the shared space level. This applies to both system and custom fields.

In addition, the following are copied:

Attachments
Backlog items: Tasks
Features: Backlog items and tasks
Tests: Data tables and sets, the current version

Not copied

Values are not copied where the value is defined at the workspace level, such as local application modules, programs, teams, and releases.

In addition, the following are not copied:

Comments, Data access categories
Tests: Runs, previous versions, automation status

REST API for copying a feature's child items

You can use the children_query request to define a parameter to be applied on the feature's child items that should be copied.

The following examples demonstrate queries for copying child items to a different workspace.

Example query	API request
Do not copy any children	`{octane_url}/api/shared_spaces/{space_id}/workspaces/{workspace_id}/features/duplicate_remote?dest_ws_id=2001&query=%22(id%3D%272001%27)%22&children_query="(id IN null)"`
Only copy children with specific IDs	`{octane_url}/api/shared_spaces/{space_id}/workspaces/{workspace_id}/features/duplicate_remote?dest_ws_id=2001&query=%22(id%3D%272001%27)%22&children_query="(id IN '1001','1002')"`
Only copy children that are defects	`{octane_url}/api/shared_spaces/{space_id}/workspaces/{workspace_id}/features/duplicate_remote?dest_ws_id=2001&query=%22(id%3D%272001%27)%22&children_query="(subtype='defect')"`

Notes

The following apply when copying features to another workspace.

Area	Description
Permissions	A feature is copied with its child backlog items. If you do not have create permissions for any of the children in the target workspace, only the children for which the user has create permission in the target workspace are copied.
Data access issues	If the data access category is used for defects, and a user can access all backlog items of the feature in the source workspace, the feature is copied together with its backlog items even if the defects' data access category in the target workspace is different and the user can no longer see the defects. If a user has permissions to copy a feature and its backlog items, but some defects are not visible because they have a different data access category to the data access category for the user's role, those defects are not copied.

Area

Description

Permissions

A feature is copied with its child backlog items. If you do not have create permissions for any of the children in the target workspace, only the children for which the user has create permission in the target workspace are copied.

Data access issues

If the data access category is used for defects, and a user can access all backlog items of the feature in the source workspace, the feature is copied together with its backlog items even if the defects' data access category in the target workspace is different and the user can no longer see the defects.
If a user has permissions to copy a feature and its backlog items, but some defects are not visible because they have a different data access category to the data access category for the user's role, those defects are not copied.

Move an item to a different workspace

You can move features and backlog items from one workspace to another in the same space. You can move one feature or backlog item at a time. When moving a feature, all its child backlog items are also moved.

To move an item to another workspace:

Prerequisites

By default, the following permissions are required:
- Move to Different Workspace permission for the item type on both source and target workspaces.
- Create permission for the item type on the target workspace.
For details, see Permission categories and types.

Note: An admin can control the permissions required for move actions using the MOVE_CROSS_WS_USE_CREATE_PERMISSION parameter. For details, see Permissions to move items.
In the item's Details tab, click More and select Move to Different Workspace.
In the Move to Different Workspace dialog box, select the target workspace, and then click Move.

Refresh the grid in the target workspace to view the change.

Item details that are moved

The following table lists the feature and backlog item details that are moved between workspaces and any restrictions.

Field	Description
Common fields	Fields vary depending on the entities that the workspaces share. For example: The Owner field is saved only if the user is part of the new workspace. Otherwise, it is left blank. The Author field is saved only if the user is part of the new workspace. Otherwise, the user who is moving the backlog item is the author. Phases that exist in the original workspace but do not exist in the new workspace are replaced with the master phase. For details, see Master phase. Releases associated with the shared space are moved, while releases associated with the workspace are not. This is available for other shared entities: application module, environments, release processes, milestones.
Attachments, comments, history	Moved to the new workspace.
User-defined fields (UDFs)	Moved if defined at the shared space level and are common to both workspaces.
Associations	Features: Associations with shared epics and the feature's child backlog items are kept. All other associations are removed. Backlog items: Associations with backlog items cannot be moved to the new workspace. All associations are removed.

Notes

The following apply when moving items between workspaces.

Area	Description
Irrelevant fields	The feature or backlog item in the target workspace might not be valid due to the removal of fields that are irrelevant in the target workspace. Any user attempting to modify the feature or backlog item must adjust it to make it valid.
Permissions to move items	Moving items requires the permissions listed in Prerequisites. If you do not have the Create permission for features in the target workspace, the target workspace is not displayed in the list of available workspaces and the feature cannot be moved. A feature is moved with all its children. If you do not have Create and Move to Different Workspace permissions for all children in the target workspace, the target workspace is not displayed and the feature cannot be moved. For example, if your feature contains two user stories and one quality story, but you do not have create permissions for the quality story entity in the source or target workspace, the feature cannot be moved. Note: An admin can control the permissions required for move actions using the MOVE_CROSS_WS_USE_CREATE_PERMISSION parameter. Previously, only the Move to Different Workspace permission was required, whereas now, the Create permission is also required to perform the move action. If the parameter value is set to true (default), the Create permission is required in addition to the Move to Different Workspace permission in the target workspace. If the parameter value is set to false, only the Move to Different Workspace permission is required in the target workspace. This is useful when the user should be permitted to move items between workspaces, but not to create new ones independently. For details, see Configuration parameters.
Data access issues	When moving a feature: If the data access category is used for defects, and a user can access all backlog items of the feature in the source workspace, the feature is moved together with its backlog items even if the defects' data access category in the target workspace is different and the user can no longer see the defects. If a user has permissions to move a feature and its backlog items, but at least one defect is not visible because it has a different data access category to the data access category for the user's role, the move action is not available for the feature.

Area

Description

Irrelevant fields

The feature or backlog item in the target workspace might not be valid due to the removal of fields that are irrelevant in the target workspace. Any user attempting to modify the feature or backlog item must adjust it to make it valid.

Permissions to move items

Moving items requires the permissions listed in Prerequisites.

If you do not have the Create permission for features in the target workspace, the target workspace is not displayed in the list of available workspaces and the feature cannot be moved.
A feature is moved with all its children. If you do not have Create and Move to Different Workspace permissions for all children in the target workspace, the target workspace is not displayed and the feature cannot be moved. For example, if your feature contains two user stories and one quality story, but you do not have create permissions for the quality story entity in the source or target workspace, the feature cannot be moved.

Note: An admin can control the permissions required for move actions using the MOVE_CROSS_WS_USE_CREATE_PERMISSION parameter. Previously, only the Move to Different Workspace permission was required, whereas now, the Create permission is also required to perform the move action.

If the parameter value is set to true (default), the Create permission is required in addition to the Move to Different Workspace permission in the target workspace.
If the parameter value is set to false, only the Move to Different Workspace permission is required in the target workspace. This is useful when the user should be permitted to move items between workspaces, but not to create new ones independently.

For details, see Configuration parameters.

Data access issues

When moving a feature:

If the data access category is used for defects, and a user can access all backlog items of the feature in the source workspace, the feature is moved together with its backlog items even if the defects' data access category in the target workspace is different and the user can no longer see the defects.
If a user has permissions to move a feature and its backlog items, but at least one defect is not visible because it has a different data access category to the data access category for the user's role, the move action is not available for the feature.