Skip to end of metadata
Go to start of metadata

Michael Kuhl 


Jira Service Desk


JIRA Project:  https://jira.hl7.org/projects/PSS/issues/PSS-1007?filter=allopenissues 



 

Done:

Overview: Upon create/edit of a “Project Scope Statement” type issue, sponsoring workgroups, co-sponsoring workgroups, management groups, and steering division boxes are required to be checked. When initial transition to workgroup approval takes place, a post-function creates a subtask for each sponsoring workgroup selected. All subtasks have their own workflow consisting of “Review, Approve, and Reject” states, and are sub-task type “PSS Approval”. When all subtasks reach “Approved” status, Parent issue (type “Project Scope Statement”) is transitioned to “Administrative Review” state. A post-function creates a new subtask for each of the checked “co-sponsoring workgroups”, “management groups”, and “Us Realm” (if applicable). Again, once all subtasks reach “Approved” parent issue is transitioned to “Steering Division” state; the transition has another post-function that creates a subtask for each of the checked “steering division”. Finally, when all steering division subtasks have been approved, the parent issue is transitioned to “TSC Review” state. They will finally approve. At each state, there is a refresh transition against the same state. This is initiated when an edit is made and contains post functions that create subtasks for each additional checkbox. All subtasks are created using a seed creation post-function by Jira Workflow Toolbox (add on). All issues are auto transitioned using listeners from Project Automation (add on) .

 

To Do:

Email to be sent to unique listserv email upon each subtask creation, dependent on subtask summary or sponsoring work groups, co-sponsoring workgroups, management group, steering division group fields. (I think using a subtask’s summary as unique identified would be easier, but then I’m the one asking for help, so take that with a grain of salt)

Example Case: Parent issue is created and “Anesthesia” is check for sponsoring workgroup. A subtask is created when “start approval” transition is initiated. An email is then sent to anesthesia@lists.hl7.org to notify that the group needs to come review. They review and approve as the sponsoring workgroup, and then the Parent issue is transitioned to “Administrative Review”. A subtask is created for “Arden Syntax” and for the “FHIR Management Group”. An email is sent to ardensyntax@lists.hl7.org and an email is sent to fhirmngment@lists.hl7.org notifying they need to come review and approve. The above email address are just examples. Email addresses will have a one to one correlation with each subtask creation but the email addresses don’t have a common naming scheme. My thought is an array would be useful. ie: “Arden Syntax” created, send email to example@lists.hl7.org.

All other notifications, including rejections, initial parent issue creation, TSC approval, and final approval do NOT need to be addressed.

 

 

 

Failed attempt:

Email notifications were set up using Project Automation but ran into trouble with calling to correct event. Jira Workflow toolbox creates subtasks by seed, but it seemed that the subtasks’ initial “issue created” event in the “create” transitions post-function was not being picked up by listeners. I think a custom script-runner script as a post-function, before the published event, on each transition would get the job done. (just a thought)

 

Contact: Joshua Procious joshua@hl7.org

 

 

 

 

  • No labels

3 Comments

  1. Michael Kuhl I've installed Group Sign Off for Jira. I checked it out again and I'm still humbly skeptical it will do what we're looking for: mainly in that it seems to require a specific list of users or security groups to be called for each approval. We will not be maintaining that within this project save for documenting, via activity logs, who the approvers actually were. I just wanted to reiterate because this one point has been the contention that has brought us from Comala, to an approval process in Jira with Security groups that worked, and finally to where we are now. 

    1. My plan is to use the set of all users (e.g. Jira Core Users or the group for the set of all PSS users) for the group for the permission to vote.  The notification will happen outside of that add-on.

      1. Ok sounds great! The group we want to limit approvals to now is hl7-trusted-users.