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; } } }

Is there a way to filter changes made to a custom field during a specific timeframe?

Andres Zamudio

Hi, Community!

I'm trying to gather insights on how often our team updates their Jira issues every quarter, month by month. There are two relevant values: "Status" and "Progress". The field "Progress" is a custom field, which is set to have a value from 0 to 100.

My first thought was to filter using JQL. This is the code that I'm using to filter the issues:

"status CHANGED DURING("2024-01-01", "2024-01-31") AND "progress[number]" CHANGED DURING ("2024-01-01", "2024-01-31")"

This, however, only seems to work when I try to get the status change value, but not the progress fields. Jira returns this message when I try to run the filter:

History searches do not support the 'progress[number]' field.

My second thought was to use a different approach with the following code:

"status CHANGED DURING("2024-01-01", "2024-01-31") AND "progress[number]" > 0 AND "progress[number]" WAS 0 DURING("2024-01-01", "2024-01-31")"

However, I am getting this feedback from Jira:

History searches do not support the 'progress[number]' field.
History searches only support string values.

I am lost here. I've been trying to find many ways to approach this, but nothing seems to work. Am I using JQL wrong? or is this the wrong way to solve this?

If anyone has any other solution, I would appreciate your input

Accepted answers

Ste Wright

Hi @Andres Zamudio

JQL history searches (i.e looking for changes) only works with a small number of system fields, like status - and not with custom fields.

JQL isn't necessarily going to return what you want either - it's going to show you issues which were updated during that month, but not how many times they've done it.

This information is in the issue history though.

A few options are below.

---

Automation:

Given it's only two fields, you could do this...

Create four custom fields...
- Number fields...
  - Status - Update Count
  - Progress - Update Count
- Date fields...
  - Status - Last Updated
  - Progess - Last Updated
Use Automation to populate them...
- Number - Count upwards each time they're updated. Clear this data once per quarter
- Date - Modify this date each time they're updated (i.e to "now")
Query these in JQL instead

---

Other:

Use the API to extract the issue history and review it
Use an App to gather this information. Perhaps an Issue History App, or one of the status tracking Apps

---

I haven't tried the Automation, but if it's of interest and you need help creating it, let us know

Ste

All comments

Ste Wright

Hi @Andres Zamudio

JQL history searches (i.e looking for changes) only works with a small number of system fields, like status - and not with custom fields.

JQL isn't necessarily going to return what you want either - it's going to show you issues which were updated during that month, but not how many times they've done it.

This information is in the issue history though.

A few options are below.

---

Automation:

Given it's only two fields, you could do this...

Create four custom fields...
- Number fields...
  - Status - Update Count
  - Progress - Update Count
- Date fields...
  - Status - Last Updated
  - Progess - Last Updated
Use Automation to populate them...
- Number - Count upwards each time they're updated. Clear this data once per quarter
- Date - Modify this date each time they're updated (i.e to "now")
Query these in JQL instead

---

Other:

Use the API to extract the issue history and review it
Use an App to gather this information. Perhaps an Issue History App, or one of the status tracking Apps

---

I haven't tried the Automation, but if it's of interest and you need help creating it, let us know

Ste

Yuliia_Borivets__SaaSJet_

Hi @Andres Zamudio

JQL supports only six fields within history searches (Assignee, Fix Version, Priority, Reporter, Resolution, Status). It doesn't work for custom fields, so you'll need to look for alternative solutions like those suggested in the previous answer.

If you are ok with third-party apps, check the Issue History for Jira (free for 30 days) developed by my team. It provides the info you are looking for. You can check all the changes made to the field "Progress" or any other.

Here is how it looks for the due date field:

jira due date history.jpg

More info: How to get history for the specific issue field in Jira

Andres Zamudio

Hi, Steffen! Thank you very much for your input. I'm working on this approach, and if you have any advice on how to set up the automation I would really appreciate it

Also, will the query filter work with these new custom fields?

Ste Wright

Hi @Andres Zamudio

The fields will be available to use in JQL - you'd need to use a different format though. For example, for the date fields it might be...

"Status - Last Updated" >= 2024-04-01 and "Status - Last Updated" <= 2024-04-30

---

In terms of building the rule, this is how I would do it...

Prerequesites

You need to add the fields first. These instructions are for a Company-managed Project, but if it's Team-managed this only impacts the Screen instructions.

You'll need to be a Jira Product Admin, and then...

Go to Settings (cog icon in top-right) > Issues
From the left-hand menu, select Custom fields
Press Create custom field
Create 4 custom fields...
- Number Field...
  - Status - Update Count
  - Progress - Update Count
- Date Picker...
  - Status - Last Updated
  - Progress - Last Updated
Add the Fields to Screens (if needed). I'd recommend having 2 separate Screens - one for the Create/Edit operations, and one for View - so these fields are not editable from the issue detail view.
- See more on issue operations on this help page: Manage screen schemes

Once you have the fields created, we'll need the 2 Number Fields' custom field IDs. To get these...

From the custom fields list, search for "Status - Update Count"
On the right-hand side of the field's row, select the breadcrumbs (...)
From the select list, select Edit details
The ID is in the URL - eg. ...default.jspa?id=10123
- For the rule below, "Status - Update Count" will be ID 10123, and "Progress - Update Count" will be ID 10456.
Repeat for "Progress - Update Count"

---

Rules

As one of the two fields is Status, 2 rules is better, to allow for the use of two different triggers.

Rule 3 is optional - but is an automated way to clear the data once a quarter.

Rule 1 - Status:

Trigger: Issue transitioned
Action: Edit issue
- Field = Status - Last Updated
  - Value = {{now}}
- Field = Status - Update Count
  - {{#increment}}{{issue.customfield_10123}}{{/}}

Rule 2 - Progress:

Trigger: Field value changed
- Fields to monitor = Progress
- Change type = Any changes to the field value
Action: Edit issue
- Field = Progress - Last Updated
  - Value = {{now}}
- Field = Progress - Update Count
  - {{#increment}}{{issue.customfield_10456}}{{/}}

Rule 3 - Clear Data:

Trigger: Scheduled
- Advanced...
  - Cron expression = ^\d{4}-(01|04|07|10)-01$
- Run a JQL search = TRUE (check box)
  - JQL - "Status - Last Updated" IS NOT EMPTY OR "Status - Update Count" IS NOT EMPTY OR "Progess - Last Updated" IS NOT EMPTY OR "Progress - Update Count" IS NOT EMPTY
Action: Edit issue
- Field = Status - Last Updated
  - Value = leave empty
- Field = Status - Update Count
  - Value = leave empty
- Field = Progress - Last Updated
  - Value = leave empty
- Field = Progress - Update Count
  - Value = leave empty

---

Notes:

You could limit the change types for Rule 2, if you didn't want to count removal of values
You could also add additional Conditions if needed - eg. in Rule 2 you could exempt a change if it's to set the field to 0
In Rule 3, you'll need to test the Cron - but this should clear the data once per quarter, on the first day of the month (i.e Jan 1st, Apr 1st, July 1st, and Oct 1st)
- You could use a Basic schedule instead, eg. "Run rule every 3 Months" but it's not specific to a month
- However, setting this in April would make the first rule run July 1st

---

Let us know if this works for you!

Ste

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-work-management

jira-work-management-cloud