I want to do a Jira issue query, but I dont know if it is possible.
I am looking at how many of our bugs have been re-opened ever. So they were worked on, closed, re-opened, and then fixed and closed again. Its a measure of how well bugs are fixed.
That query uses:
AND status was Reopened
However, we have a behaviour where we close an issue, realise that the issue needs editing, so re-open the issue to change the resolution for example, and then close it again.
I think the best way of doing this is to search for something like
'AND status was Reopened for more than 3 hours'
Is there anything like that? The data is there in the history, it is just a matter of weather we can query it or not.
There's no way to write a JQL for issues which were in a status for a given amount of time. JQL only supports searching the time an issue has been in a status relative to a date. If you are using Jira Service Desk, the usual workaround for something like this is to create an SLA for 3 hours which is triggered when the issue moves into the Reopened status, and then query for this SLA being breached.
Otherwise, there are add-ons for adding this functionality to JQL. Or add-ons for creating automations which could set a flag that you could query. Automation for Jira and Scriptrunner are popular plugins that could pull this off, and soon Automation for Jira will be built into Jira Cloud.
Related
I go the task to pause/unpause a SLA.
My attempt was using Scriptrunner, this way there was no need to develop a complete plugin.
On my development system I got it running.
What I do is, that I get the issue customfield value of the sla I have to pause.
Inside the value is a history list, adding a new pause event there and saving works, pausing the sla without moving to a new status.
I also set the boolean in the ongoing data.
The issue gets an reindex at the ende.
My problem now is, that this works so far only on my development system.
The other two systems I have tested the script wont pause the SLA.
All systems are running the same Jira 8.7.1, Servicedesk 4.7.1 and Scriptrunner 5.6.15.1-p5 versions.
All are running against a Postgres 72
Do you have an idea why the SLA pauses on one but not on a another system?
Thanks for reading this so far
Philipp
I also asked the question here:
https://community.atlassian.com/t5/Jira-Service-Desk-questions/Update-SLA-from-Script/qaq-p/1464744
Found my Answer,
the new Timeline event was created in the future.
I have read a dozen articles on here, and tried over 50 different syntax variations in task scheduler, and bat files with several different syntax variations, and it still will not work. All of the articles' answers fail, along with everything else I have tried.
Here's the task: Monday through Friday at 4:55 AM, launch a browser and navigate without user interaction to westcoastswing.radio.net. It doesn't matter which browser. Task must run Monday through Friday only. Task must run whether anyone is logged in or not, and must wake the computer to run the task. Monday through Friday at 6:15 AM, kill the browser.
Updating to a newer version of Windows is not an option at this time. A third party product is only an option once it's determined that Microsoft is deliberately blocking this functionality. Using Windows Media Player and a specialized URL found via F12 might be an option, but I have spent an even greater amount of time trying to get that strategy to work, without success.
Thanks for any help or advice. Please don't mark this as a duplicate, I have tried the existing similar articles and their solutions do not work.
Found a method that works, but only because I use MSIE only for this and nothing else.
Specify full path to IE, in quotes, in start program.
Specify URL, not in quotes, in optional arguments.
Highest possible permission.
Don't run "hidden".
I don't know why that worked, or why out of all the combinations I tried before I didn't hit on that exact one, but sorry for posting a pointless question.
We use Jira for issues bugs estimates and timesheets.
I've seen 2 approaches to using Jira and I want to hear what other people are doing.
Approach 1:
Log one feature, such as "Allow user to save as CSV". The task is assigned to a Developer and the workflow progresses from Not started, In Progress, Complete. Once done it's assigned to a Tester and they change workflow to Testing, then to Tested/Completed.
Approach 2:
Log a task/user story called "Allow user to save as CSV". Then developer logs subtasks such as, Front end, Backend and tester logs tasks such as create test plan, test right clicking. Once all dev and test sub-tasks are complete, someone marks the task as completed.
I prefer the first way, I've heard the second way is better for tracking time. It seems harder to manage what's going on with a sea of issues in Jira.
My company does first approach. This seems to be working so far ( about a year now ). With either approach I really love how everything seems to be logged in JIRA for history tracking.
I recommend using sub-tasks when you need to have work proceed in parallel. Or if the parent task is really large and the sub-tasks are around a few days each. But don't create sub-tasks unless they are needed.
Is there a way in JIRA to run a report to see how many issues were "resolved" by what users and how quickly since the issue was reported? It needs to be per user
Thanks
You can build arbitrary reports yourself with a Report Plugin Module, but my experience is that it's quite a hassle. Note that plugins will only work in self-hosted Jira installations, not in Atlassians hosted service.
Another way would be to leverage the REST API in order to fetch worklogs and process them externally.
Your requirement needs some clarifications I think. It seems you want to see the number of issues that were moved from some status to another status, or perhaps the last time the resolution field was set to a value (any value?). Then group those results by JIRA user.
A second requirement is to track the time from issue creation to the last time the resolution field was set. Again grouping by user.
I'd try using the Vertygo SLA plugin from Valiantsys to do this. It lets you define custom fields to track the time between two JIRA events such as a field updated or a status changed. I believe it can sum those fields and display grouped results in the JIRA statistics and two-dimensional gadgets.
Reports that group by user often become quite large as the number of users increases.
I am reviewing JIRA for possible use within several development teams at the company I work for. We use Scrum as a base for our project management. We have good, self-organizing teams, almost no assigned work, etc. JIRA seems great for some of these items, but something we are struggling with is handling the management of process vs technical tasks and something we call "issue bundling".
Process control. Currently we will create a story, say "The graph on the Profit and Loss report has issues with overlapping legend text". Okay, good enough. We will then create a technical sub-task, for simplicity let's say it's "Research and correct the issue". Next we have a set of process sub-tasks that we create. Peer Review, Make Build, QA Testing, Merge, Track. Each of these can then be independently assigned to users and placed into the Pending bin on our scrum board (BTW, we use a Pending, Awaiting Action, In Progress, Done, Merged model rather than a todo, in progress, done model). Pending basically means, I'm waiting if I'm next in priority. During development the programmers will grab the technical task, set themselves as assignee and move to in progress. When they are done they will move it to the Done bin and then update the Peer Review process sub task to "Awaiting Action", and set the assignee to their code partner. Emails are sent, peer review is done. When that is completed the peer review partner will move Peer Review to the Done bin and set the Make Build sub task to the build manager and move it to Awaiting Action. Build manager sees this, makes build, moves it to done and updates the QA Testing ticket to a Awaiting Action status, you get the point.
It's working, but are their any suggestions on alternatives, best practices, etc. Is creating technical and process sub-tasks not the way to go? One thing I notice is that we have to filter the issue list to hide the sub tasks and the scrum board can get pretty overwhelming for the stakeholder who just wants to see the status of the parent story. Since the parent story does not move until the sub-tasks move they don't see anything that is of interest to them, not even if the story is "in progress" while the sub-tasks are moving. Ugh.
Issue bundling. We often have a set of issues that are related perhaps tightly, but typically more general. For example, all issues that are related to reports in our software. At the present there are say 15 known issues. These issues may be on different reports in the system, with specific steps to reproduce, etc. When we are gearing up for a sprint we will select bundles of these related issues. The reason is that QA can more efficiently test a bunch of small fixes that are generally related in one pass rather than testing each report as a separate process.
Currently we move each issue to a subtask of a bundle. The bundle for example might be simply called "Report Fixes 1", and it will have, for example, 5 sub-tasks that are technical, each being a different report bug to be fixed. We can then add the process control items from above to the overall bundle. We also know that we won't merge until all items in the bundle are done, so they all get the same version.
However, as stated above, visibility is reduced as you cannot see the status easily of the subtasks now that they are in the bundle.
Again, best practice? Ideas? How are others handling this?
Brian,
Have you considered combining your process sub-tasks (Peer Review, Make Build) and your Scrum board "bins" (Pending, Awaiting Action)? Subtasks are the usual way to provide parallel tasks in JIRA, but the way you describe the whole process it sounded more linear. If each story really gets bounced from one assignee to another, just change the assignee and the status.
"Issue bundling" sounds like Epics in GreenHopper to me. You can also do a similar thing using a Labels field (standard or custom) to group issues.
~Matt
Here is how we are handling this -
The process sub-tasks you mentioned are statuses in our implementation. So, I'll have the story broken into Technical tasks that the dev finishes and then moves the story to "Pending Review" status, from where it goes to Make Build and QA Testing and so on. This is pretty much what Matt said as well. This workflow gives the stakeholders the sense of the progress that is being made on the sprint and thus is very helpful.
As such there is nothing like best practice in JIRA, it is very flexible and one can use it the way one wants/needs.
I agree with you on Epics not being a complete solution. We overcome this by adding labels and creating filters and swimlanes based on these filters.