Requirements for Moving ContentYou can only move content to a collaborative space or organization related to your credentials, and to a user whose credentials match either the collaborative space or organization of your credentials. This restriction does not apply to native apps. For more information, see the user assistance for the native app command. This table lists the requirements that must be met to move content. In this table, "Owner" is the responsibility, and "owner" is the person who is assigned ownership of content. For all changes, the person making the change must have Administrator or Author responsibility for the organization and collaborative space that currently owns the content. When you change the organization or collaborative space that owns content, the app considers that change to be a move from one secure space to another secure space.
Any user with authoring permissions in the source collaborative space and organization can move any non-Personal Management content. The ownership change can be to a user who does not have authoring credentials. Only a user with the Administrator or Owner responsibility can move content locked by someone else. This baseline behavior can be changed using ownership access rules. For more information, see Rules that Configure Ownership. For a Bookmark Root or Bookmark, the Change Owner privilege extension is not supported. For more information, see Sharing Engineering Content. Moving RulesMoving content changes the Modification Date of the content and can be done when the content is in any maturity state. When you move an object to another collaborative space or organization, or change its owner, its child instances are automatically moved with their parent reference. Possible Issues when Moving Content Between Collaborative SpacesThe content owner must monitor the integrity and the consistency of the resulting move. The Move command does not check that the content remains accessible to its original collaborative space. Changing content collaborative space ownership may result in dangling instances from the original collaborative space, for example:
When moving a reference from one collaborative space to another, move the aggregated content (instances) at the same time; otherwise, you could have dangling information aggregated inside a reference:
You can move content in a public collaborative space to a collaborative space with a higher visibility (such as changing Released content from a protected collaborative space to a public or standard collaborative space) without problems. However, changing the ownership of content to a lower visibility collaborative space (such as changing In-Work content from a protected or public collaborative space to a private collaborative space) is risky and not recommended. The Administrator should set up collaborative space ownership so that the resulting content structure (upstream and downstream) is built interactively and identically by a Leader. Otherwise, further versioning, evolution, cloning, deleting, or importing operations (on the moved content and on the non-moved content) could have problems. The user might need to move multiple pieces of content to achieve a consistent state. For example, you might need to move all versions (one by one, or by multi-selection) to ensure that versionability of the moved objects is maintained. The Administrator has Read access to any content in any the collaborative space for the organization or the user, so if a problem is detected afterward the move, the Administrator can move the content back to the original collaborative space. |