• Community
  • Products
  • Jira
  • Questions
  • How Can I Create Documentation Project tasks from Customer Issue Project Tickets via JIRA Create on Transition Plugin?

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

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?

3 answers

1 accepted

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.

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

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.

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

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.    

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

808 views 3 9
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you