How to calculate how long an issue was in Blocked — and shift its deadline automatically

[#1]

The business case

A manager asked for this: when an issue returns from Blocked to In Progress, its ETA (Planned End Date field) should automatically move forward by the time spent blocked — New ETA = Old ETA + time in Blocked. For all request types; business days only; if ETA is empty, do nothing.

Without this, every blocked issue comes back "overdue" and the dates have to be fixed by hand.

Solution options

I need one number — how many days the issue spent in Blocked. Three ways to get it:

1. Changelog — read status history on unblock, compute the difference. Nothing to store.
2. Helper custom field — write the date on enter, read on exit.
3. Issue entity property — same idea, but the date lives in invisible metadata on the issue instead of a field.

Why I chose option 3

Option 1 didn't survive contact: {{issue.changelog}} inside an automation rule returns an empty object (histories=null, total=0), so status history simply isn't readable there.

Option 2 works, but it adds a permanent custom field to the instance — screens, exports, search index — for data no human ever needs to see. Creating a field for one small feature felt like clutter.

An entity property has none of that: invisible in the UI, not indexed, nothing to configure. Its only real downside is that Jira has no built-in UI to view properties — more on that below.

Implementation

Two practical notes:

• The timestamp is stored as {{now.toDays}} (days since epoch, a plain integer like 20643). Date strings written to properties can't be parsed back by .diff(), while integer math works reliably.
• Business days are computed in two steps: from the calendar length of the pause I build a helper date ETA + calendar days, take .diff(...).businessDays between it and the ETA (.diff() works fine between two dates), and shift the ETA with .plusBusinessDays(). Note that the formula computes the equivalent shift from the current ETA rather than the business days inside the pause itself — which is actually the right question for rescheduling a deadline: what matters is how many weekends fall into the shift from the ETA.

Rule 1 — issue enters Blocked / Hold

• Trigger: Status changed → to Blocked / Hold
• Create variable time = {{now.toDays}}
• Set entity property pause_start = {{time}}

Rule 2 — issue leaves Blocked / Hold

• Trigger: Status changed → from Blocked / Hold
• Condition: Planned end date is not empty
• Create variable formula =

{{issue.customfield_10236.plusBusinessDays(issue.customfield_10236.diff(issue.customfield_10236.plusDays(now.toDays.minus(issue.properties.pause_start))).businessDays)}}

• Log {{formula}} (optional)
• Edit issue → Planned End Date = {{formula}}

Issue spends a week in Blocked → Planned End Date moves five business days forward. No cleanup needed (pause_start is overwritten on every new pause), and Blocked → Hold chains work automatically — both rules fire.

Debugging with UPEJ

With implementations like this, one question keeps coming up: how do you quickly look at the properties of an issue, a user, and so on? I constantly needed to check what's actually stored in pause_start: did Rule 1 fire, is the value a number. And for testing — move it a couple of days back. Properties are invisible, so normally that means Postman against the REST API (if you can even reach it — hello, IP allowlist) or temporary automation rules that edit and log values.

Disclosure: I'm the developer of Universal Properties Editor (UPEJ) at MOY Apps — this exact pain is why the app exists. Open the admin page, Issue properties tab, enter the issue key — all properties are visible and editable in place. Checking pause_start after each transition took seconds, and simulating a week-old pause was just editing the value by hand instead of writing another debug rule.

The rules themselves need no app — but automating on top of properties without any way to see them is painful.

Question for the community

What do you use properties for (issue, user, project and others)? Any problems or interesting scenarios you've run into?