We implemented the Rework option in our promotion requests similar to the out of the box template in 10.2.
The rework options works great, as long as they don't need to change the collection.
A secondary problem we've found is that often the promoter will forget they have a promotion in rework, and will create a new promotion request.
So we end up with a brand new promotion and one that has rework data recorded.
This leads to queue failures when it's trying to lock an object that's already locked in Under Review.
My first instinct is to check for the objects being in Under Review. Though when the second promotion is started it's at an In Work state. You could only catch the failure on the original promotion with all the data.
We perform a check of objects checked out already. We also have a terminate path as part of the Rework task if they find a duplicate promotion or need to change the collection and just can't move forward with it. Though, right now I have to play watchdog over the WfPropagationQueue watching for any failures until I implement some sort of fix/prevention because the promoter gets no notification of a failure, and even if they did they might not know what the failure message means or what they need to do about it.
A second idea might be to look for any open Promotions against a Revision. Though that would require a bit more processing.
Ideally we would want to eliminate the duplicate promotion before it even gets started, terminate it after creation, or trigger some sort of flag to the promoter that there is an open promotion.
Do these make sense, anyone have any other ideas I'm missing?