As described in the article – we’ve created a multi user custom field, a workflow with 2 transitions (one cycle transition to the same status and one to the next status). We’ve created a set of conditions – one to check if user already followed the cycle transition and one that checks if it is the last user who should approve so he can put the issue to the next status after his approval. The calculated custom field was added to show the list of users who already approved the issue. The creation of needed filters / subscriptions / gadgets is trivial – so it can be done according to your needs.
The first approach contradicts the idea of “one issue – one assignee” and brings a little chaos to the documentation – it can be hardly used in standard filters / metrics to check who delays the process, what is the bottleneck etc. So we’ve created another method of solution for that situation. We use the same multiuser custom field that will contain the information regarding the list of approvals. When the ticket comes into state that needs to be approved – it automatically creates a set of subtickets according to the custom field with the approvers list. Each subticket is being assigned to a particular person so you can use SLA and other metrics for those tickets. You can use standard filters and reports if you select that method. The final step is to use existing postfunction in one of the popular plugins to transfer the parent issue to the next stage when all the subtickets are moved to approved state. The validator blocks the movement of parent issue until all subtickets are approved.