Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How can I change the reviewer in Comala workflow after reviewers are notified?

I am experiencing this problem with the workflow where reviewers are listed and their responses are pending. I'd like to remove one of the reviewers and assign the review to somebody else . It seems that the workflow can not drop the original assignee and accept the new one. The workflow trigger is label attached to Product Requirements blueprint and the page property macro . Also, if the page is edited , the reviewers are seeing the edits instead the snapshot of the version they are asked to review; is this expected behavior? Any help would  be appreciated, point to the right article as well

3 answers

Hi Gordana, 

I'm the Product Evangelist with Comalatech. How are you assigning the reviewer initially? Is it by user name in the mark-up? Let me know and I'll see how I can help. 

As for the reviewers seeing the updated page, yes - people involved in the review process will also we see the most recent version of the page. 

hi Mike, thanks for the reply. The role is defined in the markup ( forProduct Requirements reviewers are Developer, Designer, QA lead, InfoSec Oficer ) and the name(s) for each role is added into page properties macro  (for example 

Target release

Epic                            

Status                           status macro

Document owner          @usermention

Designer                        @usermention

Developers                     @usermention

QA                                 @usermention

ISO                                 @usermention

Approver                        @usermention

This is a very small modification of original markup for Product Requirements:

{workflow:name=Product Requirement Workflow|key=com.comalatech.workflow:atlassian-requirements-blueprint|blueprintkey=com.atlassian.confluence.plugins.confluence-software-blueprints:requirements-blueprint|label=requirements|updatestatus=true|disabled=true}
{description}
h1. Product Requirements Workflow
Use the workflow to manage the different states of your Requirements
* h3. Requirements Status
From _Draft_ to Approved
* h3. Stakeholders
Designer,Developers,ISO and QA
* h3. Approvals
Approvals for the requirements stakeholders are generated
\\
\\
\\
Want to see it in action? Watch [this video|https://wiki.comalatech.com/display/AWP/Requirements+Workflow]
{description}
{workflow-instructions:style=info|title=Workflow Instructions}
Please make sure you define _Designer_and _Developers_ and _QA_ and _ISO_ so they can be assigned for review
{workflow-instructions}
{state:Draft}
{state-selection:states=For Review|usersdefined=@Designer@,@Developers@,@QA@,@ISO@,@Approver@}
{state}
{state:For Review|approved=Reviewed}
{approval:Development|user=&@Developers@}
{approval:QA|user=&@QA@}
{approval:Designer|user=&@Designer@}
{approval:ISO|user=&@ISO@}
{state}
{state:Reviewed}
{state-selection:states=Pending Approval|usersdefined=@Approver@}
{state}
{state:Pending Approval|approved=Approved}
{state-selection:states=Approved,Deferred}
{approval:Approver|user=&@Approver@}
{state}
{state:Approved|final=true}
{state}
{state:Deferred|hidefrompath=true}
{state}
{trigger:statechanged|state=For Review}
{set-message}{set-message}
{trigger}
{trigger:statechanged|state=Draft|usersdefined=!@Designer@,@Developers@,@QA@,@ISO@|initial=true}
{set-message:style=warning}You need _Developers_ , _QA_ , _Designer_ and _ISO_ users before submitting for review{set-message}
{trigger}
{trigger:pageupdated|usersdefined=!@Designer@,@Developers@,@QA@,@ISO@}
{set-message:style=warning}You need _Developers_ , _QA_ , _Designer_ and _ISO_ users before submitting for review{set-message}
{trigger}
{trigger:pageupdated|state=Draft|usersdefined=@Designer@,@Developers@,@QA@,@ISO@}
{set-message}{set-message}
{trigger}
{trigger:statechanged|state=Reviewed|usersdefined=!@Approver@|initial=true}
{set-message:style=warning}You need _Approver_ before submitting for approval{set-message}
{trigger}
{workflow}

What we find - all reviewers have to be added when the initial state changes from draft to "for review".  In case we need to change the reviewer's name (this happens for various reasons) the old reviewer is still in the workflow and the new one is not, so the workflow is stuck.  

Approval is the compliance issue for us and we need to ensure that one version of the page is approved;  does it mean that, while reviewers are changing the page, it stays in "draft" or "in review" state until all of them confirm and approve? only then it is sent to approver (approver should approve a snapshot that everyone agrees on)

Hi Gordana,

Unfortunately there is no seamless way of changing your previously-assigned reviewers when a page is mid-workflow. The best course of action is have an Admin reset the workflow back to the Draft state, and then resubmit to the “For Review” state (at which point the new assignee will be added). Instructions for having an Admin reset the workflow can be found here: https://wiki.comalatech.com/display/CWL/Administrator+state+override

As for how Workflows handles visibility of pages, let me walk through how a typical review process works based on your workflow above. Generally speaking, no one should advance the workflow until the author is happy with the content, at which point they will select the “For Review” state. Then, your reviewers will visit the page to provide their approval. The Workflow will not advance to the next state until all the reviewers have provided their approval, it will stay in the “For Review” state. If an approver provides their approval, but then a change is made to the page, that approval will be rescinded and that user must provide their approval on the new version. Only once each reviewer has approved the page will it advance to the “Reviewed” state. Does this clarify the process? Let me know :)

Hi Mike,

thanks for the comprehensive  answer. Point 1: it is good to know  that it is indeed the limitation and I wonder if the new version brings some improvements.

Point 2:  yes, that is the behavior we expect (thus the workflow as shown) but we are challenged with resolving these issues such as  multiple edits and state reset. 

I guess adjustments in the code will have to be made to implement different use case ( for example,  remove dependency on reviewers response ).

Can you share some samples of markup for different workflows?

Thanks again

Hi Gordana,

We're always trying to improve Workflows, and posts like these definitely help give the team an idea of what our users are looking for. 

If you're looking for more information about group approvals, and adjusting dependencies etc., I suggest you take a look at the "Adding Multiple Reviews" page in our documentation. As for additional sample workflows, you can check out our workflows repository here

Finally, we do offer a workflows building service as well, where we custom build a workflow to your specifications. Let me know if you would be interested in learning more about that. 

Best of luck!

Hi. I am not sure if this is still relevant to the context. For the future queries:

One can still change the reviewer once the workflow is active.

Edit the workflow using markup

Locate the state you would like to change the reviewer:

Remove any existing user or group from the located state

Add an attribute assignable=true

This will allow you to add reviewers on the page.

We had a similar challenge and created a solution where we assign all (multiple) approvers in Draft State, and then use these assignments in the next States (all approvers provide their approvals in order).

But - at each of the next States I added a second approval used just for reassignment of the originally assigned approver, if there is a need for that. I use this approval to jump to another state where I complete reassignment and then jump back to the State where approval is needed. This way you don't have to edit page and loose previously provided approvals..

I understand it is extra work, but it works for me :)
And on the Draft State, these original approvals are used for assignments only (I have "hasapproval" condition on them to prevent an approval)


See sample code below 

1. State Draft with assignments:


    {state:Draft|updated=Draft|hideselection=true}
        {approval:1. Assign or re-assign the Peer Reviewer. Must be different from SME.|hasapproval=3. SME Approval. Approval moves workflow to Peer review.|approvelabel=-|rejectlabel=-|selectedapprover=confluence-users}
        {approval:2. Assign or re-assign the Owner.|hasapproval=3. SME Approval. Approval moves workflow to Peer review.|approvelabel=-|rejectlabel=-|selectedapprover=owner_group}
        {approval:3. SME Approval. Approval moves workflow to Peer review.|rejectlabel=-|user=@SME@}
        {approval:KM Team to assign KM Reviewer.|hasapproval=3. SME Approval. Approval moves workflow to Peer review.|approvelabel=-|rejectlabel=-|selectedapprover=km_notificationt}
        {approval:Re-assign the SME - optional. Must be different from Peer.|hasapproval=3. SME Approval. Approval moves workflow to Peer review.|approvelabel=-|rejectlabel=-|selectedapprover=confluence-users}
    {state}

one SME approves, we move forward to Peer Review (I use a triggers to make sure everyone is assigned).

2. Peer review State

    {state:Peer Reviewer Approval|updated=Draft|hideselection=true}
    {state:Peer Reviewer Approval|updated=Draft|hideselection=true}
        {approval:Peer Reviewer Approval|user=@Peer Reviewer@}
        {approval:Click on Re-assign Peer to move to the Peer Reviewer Reassignment State.|approvelabel=Re-assign Peer|rejectlabel=-|weight=100}
    {state}
    {trigger:pageapproved|approval=Peer Reviewer Approval}
        {set-state:Owner Approval and CMDB Signoff}
    {trigger}
    {trigger:pageapproved|approval=Click on Re-assign Peer to move to the Peer Reviewer Reassignment State.}
        {set-state:Peer Reviewer Reassignment}
    {trigger}

Once the main approval is provided, I move to Owner Review (next apprpoval).
Second approval is used to jump to reassignment state.

Once in reassignment:


    {state:Peer Reviewer Reassignment|updated=Draft|hideselection=true|hidefrompath=true}
        {approval:Re-assign the Peer Reviewer. Must be different from SME.|approvelabel=-|rejectlabel=-|selectedapprover=confluence-users}
    {state}


Once Peer reviewer is reassigned, I jump back to the original approval State:


    {trigger:pageapprovalassigned|approval=Re-assign the Peer Reviewer. Must be different from SME.|@approvalassignees@=!@SME@}
        {set-metadata:Peer Reviewer}@approvalassignees@{set-metadata}
        {set-state:Peer Reviewer Approval}
    {trigger}

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Marketplace Apps & Integrations

5 mobile apps for Jira Cloud to boost productivity

  It’s very important to have access to the workflow process from anywhere. Especially if you manage the work of others. There is no difference whether you’re out of office, or drive a ca...

203 views 2 5
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you