nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira DC - How to build an automation or scriptrunner which display the time in Statues?

rumceisz

Hello Everyone,

however it's becoming an "oldtimer" question but really important for us. We'll move to Cloud 1 year from now but several projects need from now till the migration (so in the upcoming 12 months) a solution. I'm aware that there are several plugins, even free ones but we have now a plugin purchase freeze until the migration.

Could you help me out with an automation (the one that provided by AI doesn't work)? E:g. Time in status in In Progress.

We also have scriptrunner but nobody can change the code accordingly.

Thank you in advance!

Rumi

Accepted answers

All comments

Nikola Perisic

Hi @rumceisz

With Rovo enabled in your DC, you just need to prompt it well. It would be like this:

"For MSD project, I want to know in how many days issues are in In Progress status. Output a table format with issue key and the number of days." Replace the MSD with your project key. It's much easier, rather working with ScriptRunner.

Gor Greyan

Hi @rumceisz,

Welcome to the Atlassian Community!

Before giving you an exact solution, could you confirm your Jira Data Center version and whether you need time in the current status only, or a report showing time spent in every previous status as well?

Josh

For Jira Data Center, there isn't a native field that continuously calculates “time in current status” from the issue history. Automation can react to a transition, but it cannot reliably reconstruct and maintain all historical status durations by itself.

Native options: use the Control Chart for cycle-time reporting, or export the issue history and calculate each status interval from transition timestamps. If this must be visible on the issue, a workflow post-function/listener can write a timestamp or accumulated duration to a custom field on each transition; make the update idempotent and account for reopen/backward transitions. If you have Jira Service Management, SLAs are the native way to measure time against statuses/conditions.

For your 12-month bridge, would a Control Chart/export meet the reporting need, or must the current duration be stored on every issue for JQL?

Evgenii

Hi, @rumceisz

I made something similar with ScriptRunner scripted fields, but question is - how you want to see it?
time duration of exact status, or table of statuses and time in each status?
Solution depends from required visualization.

José León

You can do that using Script Studio in Jira Cloud, by creating a calculated field with this code, which returns the number of days in which the issue is in the current status:

/**
 * @title Days in current status
 * @summary Number of whole days since the issue last changed status.
 * @tags scripted field, number, ageing, status
 * @trigger field
 */
import { jira } from 'jira-api';

const MS_PER_DAY = 86400000;
const PAGE_SIZE = 100;

type History = {
  created?: string;
  items?: Array<{ field?: string }>;
};

const lastStatusChange = async (issueIdOrKey: string): Promise<string | undefined> => {
  // Newest last. Walk backwards so the first status item is the current stay.
  const first = await jira.get('/rest/api/3/issue/{issueIdOrKey}/changelog', {
    path: { issueIdOrKey },
    query: { startAt: 0, maxResults: 1 }
  });
  const total = Number(first.total || 0);
  if (!total) {
    return undefined;
  }

  for (let startAt = Math.max(0, total - PAGE_SIZE); startAt >= 0; startAt -= PAGE_SIZE) {
    const page = startAt === 0 && total === 1
      ? first
      : await jira.get('/rest/api/3/issue/{issueIdOrKey}/changelog', {
          path: { issueIdOrKey },
          query: { startAt, maxResults: PAGE_SIZE }
        });
    const entries = (page.values || page.histories || []) as History[];
    for (let index = entries.length - 1; index >= 0; index -= 1) {
      const entry = entries[index];
      if ((entry.items || []).some((item) => item.field === 'status')) {
        return entry.created;
      }
    }
    if (startAt === 0) {
      break;
    }
  }
  return undefined;
};

export default async function run(_getIssue, context: ScriptContext) {
  const issue = context.field?.issue;
  if (!issue) {
    console.log('Run this from the Test panel, or open an issue that shows the field.');
    return undefined;
  }

  const data = await jira.get('/rest/api/3/issue/{issueIdOrKey}', {
    path: { issueIdOrKey: issue.id },
    query: { fields: ['status', 'created'] }
  });

  // Never transitioned: it has been in the first status since created.
  const since = (await lastStatusChange(issue.id)) || String(data.fields.created || '');
  const changedMs = Date.parse(since);
  if (!Number.isFinite(changedMs)) {
    // Returning nothing leaves the stored value alone. Zero would read as "moved today".
    console.warn('No status change date on this issue');
    return undefined;
  }

  const days = Math.floor((Date.now() - changedMs) / MS_PER_DAY);
  const status = (data.fields.status as { name?: string } | undefined)?.name || 'unknown';
  console.log(`${issue.key || issue.id} has been ${status} for ${days} day(s)`);
  return days;
}

Mohammad Mahyar ahmadi

Hi Rumi,

Adding to Evgenii's point - a ScriptRunner scripted field does this without buying anything, and for the example you gave (time in In Progress) there is only one line you'd ever need to change.

I ran it on my own Data Center instance (9.6) before posting. One issue that went in and out of In Progress six times in the same afternoon came out at 22 minutes, which matches its history period by period. Another one that is still sitting in In Progress counts up to the current moment.

Setup:

ScriptRunner > Fields > Create Script Field > Custom Script Field
Template: Duration (time-tracking)
Paste the script below. If your status has a different name, change statusName and nothing else
Use Preview with an issue key you know, then save
In Custom fields, edit the new field and set its search template to Duration Searcher, then reindex the project so existing issues get a value in search

import com.atlassian.jira.component.ComponentAccessor

def statusName = "In Progress"   // the only line you need to change

def statusId = ComponentAccessor.constantsManager.statuses.find { it.name == statusName }?.id
if (!statusId) {
    return null
}

def changes = ComponentAccessor.changeHistoryManager
        .getChangeItemsForField(issue, "status")
        .sort(false) { it.created }

long totalMs = 0
Long enteredAt = null

// issue created straight into the status: there is no history row for that
def firstStatusId = changes ? changes.first().from : issue.status.id
if (firstStatusId == statusId) {
    enteredAt = issue.created.time
}

changes.each { item ->
    if (item.from == statusId && enteredAt != null) {
        totalMs += item.created.time - enteredAt
        enteredAt = null
    }
    if (item.to == statusId) {
        enteredAt = item.created.time
    }
}

// still in the status right now
if (enteredAt != null) {
    totalMs += System.currentTimeMillis() - enteredAt
}

return totalMs ? (totalMs / 1000) as Long : null

A few things about how it counts. It matches the status by id, not by name - the history keeps the name the status had at the time, so after a rename a name-based script quietly misses the old entries. If an issue was created straight into the status, there is no history row for that, so it starts from the created date. And if the issue is still in the status, it counts up to now.

One thing to know before you build filters on it: ScriptRunner calculates the value when the issue is displayed or updated. The issue view is always current, but JQL works on the indexed value, so for an issue that is still in In Progress the number you search on is from its last update. For finished stays it doesn't matter.

For more statuses, copy the field and change the one line. It's clean in the editor on 9.6 (no static type checking errors) - if you're on 10.x or 11.x and something complains, post the error here.

Hope that helps.

Dr_ Ankita Mehta-OpsHub_ Inc

Hi @rumceisz,

If the immediate requirement is simply tracking how long an issue stays in In Progress, I’d separate that from the migration itself:

For the next 12 months: If you already have ScriptRunner but don't have someone available to modify scripts, a built-in automation approach may be easier to maintain than introducing another scripted solution.
For Time in Status: Make sure the automation records the transition into and out of In Progress rather than relying only on the current status value.
For reporting: If you need historical time-in-status data, consider where that data will live and how it will be carried into Cloud during migration.
For the migration: Avoid building a temporary solution that creates a large amount of custom data you'll later need to migrate or recreate.

Since you're planning the Cloud move in about a year, you may also want to explore OpsHub Migration Manager (OMM), a standalone, purpose - built migration platform for the migration phase. It supports phased or full migrations with no downtime, disruption, or data loss, while preserving historical data such as comments, attachments, relationships, and field mappings. Sharing some collaterals around JIRA DC to Jira Cloud migration on Atlassian marketplace and Atlassian Community which, I hope, adds value to your migration journey:

All the best for your migration journey! :)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

jira

jira-data-center

time-in-status