Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-34103

Ability to use operator WAS / WAS IN / WAS NOT / WAS NOT IN in custom fields

    • Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • 12
    • 16
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      Currently, these operators can be used with the Assignee, Fix Version, Priority, Reporter, Resolution and Status fields only when using JQL. It would make a good improvement to have those working for custom fields as well (e.g multi-select fields).

        1. 100-105 Exam Questions.pdf
          722 kB
        2. 200-105 Exam Questions.pdf
          245 kB
        3. 200-125 Exam Questions.pdf
          606 kB
        4. 210-250 Exam Questions.pdf
          183 kB
        5. 210-255 Exam Questions.pdf
          329 kB
        6. 210-451 Exam Questions.pdf
          184 kB
        7. 210-455 Exam Questions.pdf
          184 kB
        8. 220-1001 Exam Questions.pdf
          261 kB
        9. 220-1002 Exam Questions.pdf
          184 kB

            [JRACLOUD-34103] Ability to use operator WAS / WAS IN / WAS NOT / WAS NOT IN in custom fields

            Atlassian Update - August 2023

            After some analysis, we've found that this ticket is a duplicate of the request JRACLOUD-27641 – Implement history search aka WAS and CHANGED operators for custom fields which has more votes.

            We encourage you to watch and vote on the above instead. All internal ticket references on this ticket have been transferred. If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.

            Anusha Rutnam added a comment - Atlassian Update - August 2023 After some analysis, we've found that this ticket is a duplicate of the request JRACLOUD-27641 – Implement history search aka WAS and CHANGED operators for custom fields which has more votes. We encourage you to watch and vote on the above instead. All internal ticket references on this ticket have been transferred. If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.

            Grace D added a comment -

            +1

            Grace D added a comment - +1

            +1

            Scott Gast added a comment - +1

            Bill Gould added a comment -

            Would be very useful to add this

            Bill Gould added a comment - Would be very useful to add this

            K Daniels added a comment -

            This is very much needed.  Please implement.

            K Daniels added a comment - This is very much needed.  Please implement.

            +1 This is much needed changes need to be done. Currently, there is no way to filter the issues by using custom fields like show the issues where custom field values changes before <this date> etc. 

            I am using Xporter add-on for the reporting purpose. Its an awesome tool to export the issues details as we want but its not capturing the history changes of the custom fields because JQL does not provide history search support to the custom fields. This is a limitation. Because of this, we are looking for other alternatives like script runner to create own custom fields and export the history changes but using tool like script runner would very difficult for the user who is not good enough in the javascript. I do vote for this change. 

            kanwarpreet singh added a comment - +1 This is much needed changes need to be done. Currently, there is no way to filter the issues by using custom fields like show the issues where custom field values changes before <this date> etc.  I am using Xporter add-on for the reporting purpose. Its an awesome tool to export the issues details as we want but its not capturing the history changes of the custom fields because JQL does not provide history search support to the custom fields. This is a limitation. Because of this, we are looking for other alternatives like script runner to create own custom fields and export the history changes but using tool like script runner would very difficult for the user who is not good enough in the javascript. I do vote for this change. 

            John Price added a comment -

            We would definitely like this.  We have a custom field that tracks a risk status (Red/Amber/Green) and would like to know when the status changed.  Please implement!

            John Price added a comment - We would definitely like this.  We have a custom field that tracks a risk status (Red/Amber/Green) and would like to know when the status changed.  Please implement!

            ++1 - this would be very helpful - bugzilla allows it

            Matt Morrison added a comment - ++1 - this would be very helpful - bugzilla allows it

            Nick Oman added a comment -

            +1

            Nick Oman added a comment - +1

            +1 

            Anna Prostrollo added a comment - +1 

            Ashbal added a comment -

            History searches for Custom fields is a very important enhancement that my organization requires. Please add this enhancement asap.

            Ashbal added a comment - History searches for Custom fields is a very important enhancement that my organization requires. Please add this enhancement asap.

            +1...

            We want to track how many times 'dueDate' got changed for a task . Kindly help.

            Ankit Sharma added a comment - +1... We want to track how many times 'dueDate' got changed for a task . Kindly help.

            +1

            Tyler O'Neal added a comment - +1

            Madelyn Meek added a comment - - edited

            We really need this feature on one of our custom fields to try and understand better the way our issues are moving about across different teams!  It would also be useful to have the 'Changed' historic search range too

            Madelyn Meek added a comment - - edited We really need this feature on one of our custom fields to try and understand better the way our issues are moving about across different teams!  It would also be useful to have the 'Changed' historic search range too

            I believe that this would be a great feature to have but I also believe Atlassian will never implement this.

            Having such a feature would increase the index size substantially and will cause serious performance impact on medium and large scale systems.

            Emre Toptancı [OBSS] added a comment - I believe that this would be a great feature to have but I also believe Atlassian will never implement this. Having such a feature would increase the index size substantially and will cause serious performance impact on medium and large scale systems.

            Today we dont have an option to query JIRA history. This would be an great improvement for JIRA, if Atlassian include JQL to query customfields history on such as single select and multi select fields.

            Ranganath HV added a comment - Today we dont have an option to query JIRA history. This would be an great improvement for JIRA, if Atlassian include JQL to query customfields history on such as single select and multi select fields.

            +1

            So important. For us, we have user picker fields to track involved individuals on a ticket (that are not the assignee), and we really want the ability to send notifications like assignee if one of these custom name fields is updated. To do that, we need to be able to query on CHANGED TO with a time condition. Can't wait for this feature, hopefully it makes the cut.

            Jason Golden added a comment - So important. For us, we have user picker fields to track involved individuals on a ticket (that are not the assignee), and we really want the ability to send notifications like assignee if one of these custom name fields is updated. To do that, we need to be able to query on CHANGED TO with a time condition. Can't wait for this feature, hopefully it makes the cut.

            +1
            This feature would be brilliant for our teams. Can't wait to have this on-board.

            Vijay Padmanabhan added a comment - +1 This feature would be brilliant for our teams. Can't wait to have this on-board.

            +1

            Same here: would be great to see this in JIRA core.

            Erik Allaert added a comment - +1 Same here: would be great to see this in JIRA core.

            +1

            Would be an extremely useful feature for us to utilize as well.

            Kane Mortimer added a comment - +1 Would be an extremely useful feature for us to utilize as well.

            +1

            Looking forward to this functionality.

            Nino Kienberg added a comment - +1 Looking forward to this functionality.

            Watching the issue.- would love a resolution to this.

            luke_majewski added a comment - Watching the issue.- would love a resolution to this.

            Don't forget "level" field !!!

            Emmanuel Rouillard added a comment - Don't forget "level" field !!!

            "Was" is a very powerful operator and not supporting custom fields is a shame. (All change history is kept in the same database table whether it is a system field or not so it should not be very hard to implement)

            Emre Toptancı [OBSS] added a comment - "Was" is a very powerful operator and not supporting custom fields is a shame. (All change history is kept in the same database table whether it is a system field or not so it should not be very hard to implement)

            Hi Atlassian JIRA team,
            Is this request on the roadmap this year? These types of filters/reports keep getting requested by upper management(Exec Committee, directors, vps) here at QAD and we keep telling them we can provide them this information. I would rate this a little higher than minor. The business value is certainly higher. Thanks for you consideration.

            Regards,
            Pat

            Pat Pigatti added a comment - Hi Atlassian JIRA team, Is this request on the roadmap this year? These types of filters/reports keep getting requested by upper management(Exec Committee, directors, vps) here at QAD and we keep telling them we can provide them this information. I would rate this a little higher than minor. The business value is certainly higher. Thanks for you consideration. Regards, Pat

            As part of our release process after a specific date we lock down a specific release from any further code changes. We do have an exception approval process where a team member can request an exception from our configuration control board (CCB) to put a change in our release branch. We have a custom field which represents the states for the exception (CCB Requested, CCB Approved, and CCB Rejected). As part of improving our overall exception approval process, we would like to query when the custom field changes to the state such as CCB Approved. We have an ecosystem of over 300 developers who could be making exception requests and this would allow us to get metrics of when these requests are being made. With the current custom field that we have we can get the total count of exception requests that were approved but there is not a programmatic way to know when the request was approved.

            Steve Capie added a comment - As part of our release process after a specific date we lock down a specific release from any further code changes. We do have an exception approval process where a team member can request an exception from our configuration control board (CCB) to put a change in our release branch. We have a custom field which represents the states for the exception (CCB Requested, CCB Approved, and CCB Rejected). As part of improving our overall exception approval process, we would like to query when the custom field changes to the state such as CCB Approved. We have an ecosystem of over 300 developers who could be making exception requests and this would allow us to get metrics of when these requests are being made. With the current custom field that we have we can get the total count of exception requests that were approved but there is not a programmatic way to know when the request was approved.

            We need it too! Currently there's no way to listen to all the changes on a custom field. When you have lot of people making changes on the same ticket, the only way to know who has updated it, is to go through the history logs manually. This process is tedious when you want to watch 100 tickets daily!

            Cheers,
            Nikhil

            Nikhil Joshi added a comment - We need it too! Currently there's no way to listen to all the changes on a custom field. When you have lot of people making changes on the same ticket, the only way to know who has updated it, is to go through the history logs manually. This process is tedious when you want to watch 100 tickets daily! Cheers, Nikhil

            Yes, ability to do historical searches on custom fields of different types (select list, for example) would be a great improvement.

            Hemal Udani added a comment - Yes, ability to do historical searches on custom fields of different types (select list, for example) would be a great improvement.

            Joe F. Lee added a comment - - edited

            The best option would be if admins were allowed to specify if a custom field should be included into the history search or not. This ticket should include all history based operators, including:

            CHANGED
            This operator has the following optional predicates:

            • AFTER "date"
            • BEFORE "date"
            • BY "username"
            • DURING ("date1","date2")
            • ON "date"
            • FROM "oldvalue"
            • TO "newvalue"

            Thanks,
            Joe

            Joe F. Lee added a comment - - edited The best option would be if admins were allowed to specify if a custom field should be included into the history search or not. This ticket should include all history based operators, including: CHANGED This operator has the following optional predicates: AFTER "date" BEFORE "date" BY "username" DURING ("date1","date2") ON "date" FROM "oldvalue" TO "newvalue" Thanks, Joe

              Unassigned Unassigned
              jspaniol Jeison
              Votes:
              189 Vote for this issue
              Watchers:
              101 Start watching this issue

                Created:
                Updated:
                Resolved: