Sidehistorik
...
| Tip |
|---|
A. Assigning the Issue to another user (e.g. getting it done/out of sight) B. Money/Bonus/goodwill C. Making a targetSerious goodwill |
Most of the time, "A" is the common (and powerfull) reason that drives the normal JIRA user.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Now, Support Managers whan what to log all times in all of the JIRA "phases" - hence 3 times:
- Diagnose done (Status going from Open ->Under investigation)
- Investigation Done (Status going from Under investigation -> Under Resolution)
- Resolved (Status going from Under Resolution -> Resolved)
In real life, if the JIRA user handling the Incident is that same, he will typically make the 2 last transitions right after each other, or perhaps if this is late and he is tired, the next morning.
I have seen this all the time in reallife systems, users does not transist Issue unless one of the reasons above is the motivator.
The solution is 2 parts:
A. Only to make steps that fullfills,
B. Make a "post" function that collects/enter the correct times. In the case above, the Service is down before the Incident is created, and up before the user resolves the issue, there times can be entered manually.
The use of Plugins and manual code
...