Problem/Motivation
We are migrating a site where content creators are maintaining content simultaneously on both the source and destination. All nodes come over during an initial migration, but if a content creator begins editing on destination, they should be able to "lock" that node in destination forever, especially after a rollback. No further changes from source should ever come through.
Our approach is fairly simple: on a destination node, tag it with a specific `tid` and check for that `tid` in a process plugin. If the destination node has that tid present, throw `MigrateSkipRowException($message, true)`. This process could be achieved any number of ways, but this is just our example workflow.
The problem lies in the `MigrateSkipRowExeception` class and in `MigrateExecutable` where the only option available is to save it to the map which only marks the record as STATUS_IGNORED and moves on. I need to be able to flag these records with `ROLLBACK_PRESERVE` too. The `MigrateExecutable` class doesn't even seem to account for this flag.
tldr: There is no apparent way to not only skip a row after initial import but also prevent it from being rolled back.
Steps to reproduce
1. Create a migration where a node is created on initial import, but skipped on update
2. Roll back the migration
3. Node has been deleted, but we want it to be preserved
Proposed resolution
1. Add an optional third parameter to `MigrateSkipRowException` called `$preserveRollback` (defaulted to FALSE)
2. In `MigrateExecutable`, add logic to check for that value and set the `rollback_action` parameter of `$id_map->saveIdMapping()` to either `ROLLBACK_PRESERVE` or `ROLLBACK_DELETE` accordingly.
Remaining tasks
N/A
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A