Move has been scaffold in art #9563, the goal of this epic is to make it complete (as complete as possible).

Strategy

The strategy for a complete move of artifact is slightly different of the original one. It's "duck-type" based, it means that a field value will be moved if:

• both source and target field have the same name (eg title)
• both source and target field have the same or compatible type. Compatible types means:
  • string -> text
  • date -> date/time
  • integer -> float
  • source list fields values (for static binding) must exist in target
  • everything that is based on user groups (user & group list binding, permission on artifact) will be moved using user group name matching. However when there is a user involved the user must exist in the target user group otherwise to be moved.

This strategy allows to move all fields but comes with a down side (regression) that it's no longer possible to move artifacts with incompatible names. For instance moving a User Story, whose Title semantic is bound to i_want_to field, to a Task, whose Title semantic is bound to summary field.

However we think that this use case, if it exist, should be rather marginal and the full move feature has more value.

The move still behaves as originally designed: when something cannot be moved because incompatible structure, the user gets a warning about it but can decide to force move (and loose the information)

Limitations & edge cases

• Artifacts in trackers that use encrypted_field cannot be moved.
• Artifacts with _mirrored_milestone links (forward or reverse) cannot be moved (it's Milestones in Program Management)
• Artifact links:
  • when the link type is a system one (_is_child, covered_by)
    • the type is removed at move.
    • in the "move" changeset, there is an indication that type has been cleared (with source type)
  • when the link type is a custom one (defined by site admin), the type is moved.

In order to get a better grasp of the problem of moving artifact links, let's take an example. Given that we want to move User Story B that is in a hierarchy:

Epic A
`-- User Story B
        |-- Task 2
       `-- Task 1

When we move User Story B in another project we need to:

• Update Epic A to remove _is_child type between Epic A and User Story B because all the features that rely on parent/child relationship (agile dashboard, etc) assume that the hierarchy is in only one project.
• At move of User Story B, remove _is_child on links to Task 2 and Task 1 for the same reasons.

We keep the links so we can also move the Task (and possibly the epic) and after move of everything it's possible to set hierarchy again.