I'm trying to create a scripted field to show the Total Time in Current Status with excluding the weekends.
unable to remove the weekends from the script.
Thanks
Hi @TN Raju
For your requirement, you could try the solution provided in the Adaptavist Library.
So in your case, you will need to use the changeHistory to get the date range the issue was in a particular status and update the sample code accordingly.
Thank you and Kind regards,
Ram
Hello @TN Raju
Additionally, performing this calculation solely through scripting can have performance implications as the script runs every time an issue is displayed, which may be problematic for older issues.
As an alternative , I guess you can try Time in Status for Jira Cloud or Time Between Statuses developed by my team SaaSJet.
Time in Status for Jira Cloud will be an option for you too if you are already switching to cloud version. You will see the Total Time in Current Status and even more with 7 types of reports that build in our add-on. also you will be able to exclude the weekends easily with work calendars.
See how Time in Status for Jira Cloud works:
Another option is Time between Statuses. This add-on, which measures connections in the workflow, through a transition time in specific issues.
You can customize your Cycle and Lead Time reports by adjusting the app interface fields such as: Type of Project Date range Time Format Multi Calendar (to configure non-working hours and different calendars same as in Time in status for Jira Cloud.)
Add-ons have a 30-day free trial version and free up to 10 users.
Please, let me know if you have any questions
Hope it helps 😌
Valeriia
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @TN Raju
If you prefer to use a marketplace app, you can try Status Time Reports app developed by our team. It mainly provides reports and gadgets based on how much time passed in each status. Status durations are calculated according to the working calendar you define. Once you enter your working calendar into the app, it takes your working schedule into account too. That is, "In Progress" time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM, will be a few hours rather than 3 days.
Here is the online demo link, you can see it in action and try without installing the app. For your case, you can have a look at Time in Status for Each Issue report.
If you are looking for a completely free solution, you can try the limited version Status Time Free.
Hope it helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I tried myself such thing without success - so i use status time free plugin for this - in dc version.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @TN Raju
As others have pointed out, this is possible but certainly not easy. You will need to build separate scripted fields for each status you want to see and it is a really hard calculation. Besides, this is not a cheap calculation to make by script. Remember, the script will run every time the issue is displayed. This might cause significant performance problems, especially on older issues.
The data needed for such a measurement is present in each issue's history but Jira does not give this as a ready-to-use report. For that, you will need to use a marketplace app.
Our team at OBSS built Timepiece - Time in Status for Jira exactly for this. It is available for Jira Server, Cloud, and Data Center.
Time in Status mainly allows you to see how much time each issue spent on each status or each assignee.
The app can create reports showing both resolved and unresolved issues.
You can combine the time for multiple statuses to get metrics like Issue Age, Cycle Time, Lead Time, Resolution Time etc.
For all numeric report types, you can calculate averages and sums of those durations grouped by the issue fields you select. For example total in-progress time per customer or average resolution time per sprint, week, month, issuetype, request type, etc. The ability to group by parts of dates (year, month, week, day, hour) or sprints is particularly useful here since it allows you to compare different time periods or see the trend.
The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well. It supports both Company Managed and Team Managed projects for Jira Cloud.
Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts.
Timepiece - Time in Status for Jira
EmreT
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Radek Dostál is correct - this is not easy to do but if you are open to a 3rd party we can help at minware. Our tool provides a weighted time allocation metric called Dev Days that accommodates nights, weekends, and all time zones globally:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
While this is possible, it's certainly not easy because you need to take into consideration different user time zones, possibly different working hours, in grand scheme of things, some teams might work 7 days a week, some not. Using https://docs.oracle.com/javase/8/docs/api/java/util/Calendar.html you can get the "start" and "end" milliseconds, with the Calendar, you would be able to infer from the data which portion is inside weekend, which is outside of it, but it's, yet again, not so simple because then you also need to account for the possibility of multiple weeks.
All in all doing this with pure "start" and "end" times is computationally heavy, due to multiple time zones and user requirements, further quite complex. Bear in mind that scripted fields do not provide a reliable index to search on (the value will not be re-indexed/stored outside of the issue itself being updated).
For all intents and purposes, I would try to discourage doing this through scripted fields, because it will have a performance overhead and likely not provide you with the functionality you're after.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.