Change lifecycle

The change lifecycle mutation takes the work item type and a mapping as arguments.

You need to provide a mapping for a status in the old lifecycle if the old status is not in the new lifecycle and the status is in use.

So we can perform a check whether there are issues with statuses in the old lifecycle that don't exist in the new lifecycle. If that's the case we can raise an error. So technically there might be cases where a mapping is not required.

All statuses that exist in both lifecycles don't need a mapping.

Mapping is based on the Draft: POC for mappings approach for custom sta... (!199448)

statusMappings: [
  {
    oldStatusId: "gid://gitlab/WorkItems::Statuses::Custom::Status/5"
    newStatusId: "gid://gitlab/WorkItems::Statuses::Custom::Status/2"
  }
]

Also handle case where a status was removed with mapping to a new status and then the lifecycle is changed for the work item type to a new lifecycle where the status exists again. In that case we need to set the valid_until date on the mapping record!

We said they "can" provide a mapping and this mapping will be used for the issue work item only in this example. That's fine, but we need to keep in mind that the mapping needs to be limited to NOW when the status exists in the new lifecycle. If we don't do that, it'd be impossible to attach the status to an issue because it'd always map to another status.