How Can I Create Documentation Project tasks from Customer Issue Project Tickets via JIRA Create on Transition Plugin?

[Mark Buckingham]

When one of our a customer issue tickets is resolved and passes QA, I'd like to have a ticket created automatically in a separate project (Documentation) so that development can close/resolve their issues separately from the documentation specialists, and the new ticket can be reviewed to see what (if any) documentation updates are necessary. My experience with the "Create on Transition" plugin is that it will only make a sub-task within the same project. Is there a way to have Jira (using CoT or some other plugin or method) automatically create that separate ticket and assign it to the appropriate project?

[Bob Swift · Accepted solution]

JIRA Create on Transition Plugin only does subtasks at this time. You can use the JIRA Clone-Plus Plugin to define an customized clone action (not workflow) to create a new issue based on information in the original issue.

[Mark Buckingham]

Is cloning always a manual process or could it be automated at a certain transition?

[Bob Swift]

Yes, others have automated that using a URL via a workflow, although I don't know of an example for that. Probably they used the ScriptRunner. The easiest way to see the URL is to run the cloneIssue action from the JIRA Command Line Interface with the -v option to see the url used.

[Jim Reynolds]

You have to make the documentation as part of the Agile flow. It cannot live outside of Agile. You have to do it inside the Jira ID (Bug or Story) You can use Sub-task OR create documentation field(s) inside the Jira form and transition screens. You cannot create a new Jira ID for Docs and link it to the Bug or Story, the Developers will not go to it. I have tried several ways and I ended up with this method.

I purchased a module from a company called GetCider (getcider.com) called Dynamic Documentation. This product uses Dynamic Forms and JQL queries to automatically create HTML Release Notes in real time. I love this product and every team said it has made their documentation task so much better.

There are fields that the Developers fill out regardless if the Jira ID needs to be documented or not and is REQUIRED. The fields are called Developer Notes and is best practices. This information is used by QA for testing and the Product Owner. This should be required information for QA to properly test. These fields feed into the Release Notes and are modified for external viewing when added to the Release Notes by the Developer, QA and Product Owner.

For Bugs the fields are…

Developer Notes: Affected Areas

Developer Notes: Impact Analysis

Developer Notes: How Dev tested it

Developer Notes: Root Cause

The Product Owner, Developer or QA Engineer answers the question “In Include in Release Notes” Y/N When they select Yes they select the type (Fixed Defect, Known Issues, Enhancement, Limitation or New Feature. The JQL query will pull this into the specific area of the HTML Release 

We configured the JQL query to only display Closed items. Now that we made it part of the workflow and the QA Engineer should do a final scrub of the Release Notes. The Technical Writer will review once the Jira ID is Closed. The Product Owner owns the full feature description. 

The Developers, QA and Product Owners are documenting each Bug or Story as the move them through the workflow and the Technical Writers do the final review, audit and corrections. 

You need to define what goes into the Release notes as this responsibility is now everyone. For example 

Fixed Bugs in Release Notes

Fixed Bug is Linked to a Support/Field issue

Fixed Bug changes UI or functionality

Fixed Bug changes UI or functionality   

Known issues or limitations

NON Closed Bug linked to a Support/Field issue

NON Closed Bug is NOT Linked to AND the Severity is Critical or High AND is pre-existing or introducing with the Release

Non Closed Bug with new features(s) should be demoed and agreed upon with the Product Manager  

I can’t go into all of the features of the GetCider tool (Dynamic Release Notes) but it has solved some big headaches for us.    

[Srini Srini]

To add on - use ScriptRunner plugin and configure a post function to the workflow step to Clone an Issue and Link in another Project

-Srini