How to use jql for missing Baseline end date calculations

Hi @jivan_patil 

JQL can't compare two fields to each other — the right-hand side of a clause has to be a literal value or a function, so resolutiondate > "Baseline End Date" treats the field name as text. That's a JQL limitation, not a syntax issue.

The usual workaround is to have Automation record the result in a field you can query:

1. Create a marker field (a label like missed-baseline, or a checkbox / number field).
2. Automation rule —
   Trigger: Issue transitioned to Done (or Field value changed: Resolution).
   Condition: Advanced compare — {{issue.resolutiondate.diff(issue.Baseline End Date).days}} greater than 0.
   Action: Edit issue → add the label / set the field.
3. For issues already resolved, run a one-off scheduled/manual rule with the same condition over statusCategory = Done AND "Baseline End Date" is not EMPTY to backfill.

Then your count is simply labels = missed-baseline (or whatever field you chose).

If you don't want to add fields, the other option is a JQL-extension app — several on the Marketplace support field-to-field comparisons in search.

Hi @jivan_patil 

You can use ScriptGenie (full disclosure: I am the developer) to define custom JQL functions. See example below:

Hi @jivan_patil,

The marker field plus Automation route is the right shape for this. One detail to check before you build it, because it silently inverts the result: the sign of the diff comparison.

Atlassian's own example is the giveaway. {{now.diff(issue.created).weeks}} returns -4 for an issue created four weeks ago, because when the second date is earlier than the first, the value comes back negative.

Applied to your case, {{issue.resolutiondate.diff(issue.Baseline End Date).days}} puts resolution first and baseline second. A ticket that missed its baseline has a baseline earlier than its resolution, so that expression is negative, and a greater than 0 condition would tag the tickets that finished early instead. Either use:

• {{issue.resolutiondate.diff(issue.Baseline End Date).days}} less than 0, or
• swap the operands: {{issue.Baseline End Date.diff(issue.resolutiondate).days}} greater than 0

I'd test the condition on two known tickets, one late and one early, and read the audit log before backfilling anything.

Two extras that tend to help here:

• businessDays works as a unit, so .diff(...).businessDays gives a lateness figure that ignores weekends. .abs and .prettyPrint are available too if you want the number stored in a readable form.
• Referencing the custom field by its ID rather than its display name is more reliable in smart values, particularly for names containing spaces.

Worth adding Field value changed: Baseline End Date as a second trigger as well. Otherwise a re-baselined ticket keeps a marker that no longer reflects the dates.

Best,

Ivan