Sidehistorik
I've been working on Templating in JIRA, without speding spending (a lot) of money on a plugin for the 2000 user JIRA that I manage at work.
The first solution was making a TEMPLATE Project and the use of Clone++ use Clone Plus for cloning Issues to the real projects, but the main problem is , that issues in the TEMPLATE project does not have the specific field and field configuration properties for Custom Fields and Field Configurations for the real project, so tempates can be fully filled to a satisfying level before cloning .
...
the template issue to a real issue.
So, in the second attempt, I have created a lot of objects that works "in parrallelparallel" of the real isssues, in the case ITIL:this case ITIL processes.
| Tip |
|---|
The solution below works with the standard Clone function in JIRA, but is more flexible with the Clone Plus Plugin, which is not so expensive. Especially, check out the possibilities in https://bobswift.atlassian.net/wiki/display/JCPP/clone-plus.properties |
Topics
Indholdsfortegnelse
Template Issue Types
New Template Issue types created:
| Issue Type | Template Issue Type | |||
|---|---|---|---|---|
| Incident | Incident Template | |||
| Change | Change Template | |||
| Service Request | Service Request Template |
Workflow
Each Template is assigned to a very simple workflow:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
The workflow has no real value, as cloning is always possible, so Its only a signal to the user and the status field can be used in filters.
Notifications
And this The workflow and Notifications is sending (virtually) no notifications at all, and as this is pointless, so on Post functions , the "Generic Event" is replace replaced with a new event "No Notifications" I have implemented under "Events" and "Notification Schemes"
Screens
As the template are created in real projects, all fields and field-configurations (and components) are present with the Template are created.
...
| Issue Type | Screen |
|---|---|
| Incident | Incident Screen |
| Incident Template | Incident Template Screen |
| Change | Change Template |
| Change Template | Change Template Screen |
| Service Request | Service Request TemplateScreen |
| Service Request Template | Service Request Template Screen |
Looking like this in JIRA:
with Operation(s):
A sample for the Incident Screens:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
| Advarsel |
|---|
A lesson learned the hard way here: Field not on the screen is not the same as the field being empty or none existing. Thus, cloning an "Inciden"t to an "Incident Template" will copy all fields, but they cant be seen afterwards. |
Filters
In general, filters should exclude the "* Template" issuetypes.
Using Templates
I use the templates in 2 ways - cloning them from a JIRA Dashboard and referencing them from Documentation in Confluence:
JIRA Dashboard
Documentation in Confluence
Here in the sample, a JIRA JQL selecting the correct "Incident Templates" are shown on the Incident Management Procedure:
Enhance Cloning for users
For JIRA, I have made a Custom Field of the Type "Message Custom Field (for view)" From the JIRA Toolkit, containing this code as "Default Value":
| Kodeblok |
|---|
<div class="field-group aui-field-wikiedit comment-input">
<a href='' target='_self' id='templatenclone' class='aui-button aui-button-primary aui-style'>Click to Clone</a>
</div>
<script>
AJS.$(document).bind(JIRA.Events.NEW_CONTENT_ADDED, function(event, dialog) {
AJS.$('#templateclone').attr('href','https://myserver.domain/secure/ClonePlusStart!default.jspa?id='+AJS.$('#key-val').attr('rel'));
});
</script> |
Where the somewhat obscure code
| Kodeblok |
|---|
AJS.$('#key-val').attr('rel') |
Get the Issue ID in the database. Inprovements here could be nice!
Rendering on the "Incident Template" Screen, the Custom Field looks like (See Making a ADG like button):
