Field Duplication

James Saint-Amour

I accidently posted this in the wrong place so reposting here for the right audience

---

I am working on auditing all of our fields in our Jira environment and deleting potential duplicates. 

 

I'm noticing cases where a field shows:

• No Contexts
• No Screens
• Date Last Used = None

However, when I run a JQL query against that same field, I can find issues that still contain values in the field.

In situations where the field administration page and JQL results appear to conflict, which source should be considered authoritative?

Specifically:

1. What exactly does the "Date Last Used" column track?
2. Can a field legitimately contain issue data while showing no contexts, no screens, and no last-used date?
3. During a field cleanup effort, should JQL issue results be trusted over the metadata shown on the field administration page?

Alexandre Pezzini

In this situation, JQL is the authoritative source for data existence, while the administration page reflects the current configuration state.

1. Why JQL shows values while Admin shows "No Contexts"

This conflict occurs because of how Jira handles historical data versus current configuration:

• Historical Data: If a field previously had a context and was used to store data, that data remains in the database even if the context is later deleted or the field is removed from all screens.

• Configuration State: The "No Contexts" and "No Screens" indicators only tell you that the field is not currently available for new data entry or display in the UI. It does not mean the field is empty.

• Authoritative Source: If JQL returns results, the data definitely exists in those work items. Deleting a field with "No Contexts" will still result in the permanent loss of that historical data.

2. Understanding "Date Last Used = None"

The "Date Last Used" feature is a helpful audit tool, but it has specific behaviors:

• Definition of "Used": This date typically updates when a value is set or changed in the field. If the data was entered years ago and the field hasn't been updated since tracking began, it will show as "None."

• JQL vs. Usage: Simply searching for a field via JQL does not count as "using" the field for this administrative metric.

3. Would the Custom Field Optimizer help?

Based on your description, you are likely already using the Custom Field Optimizer (or the optimized Fields view).

• How it helps: It highlights fields that have a Global Context but are only used in a few projects, suggesting you "optimize" them by narrowing their scope to improve performance.

• The Risk: The optimizer might suggest a field is "unused" if it hasn't been updated recently. However, it doesn't always account for the historical data that JQL can still find. Always trust JQL before taking the optimizer's suggestion to delete a field.

Recommended Next Steps

1. Trust JQL: Always use JQL ("Field Name" is not EMPTY) to verify if data exists before deleting.

2. Export Data: If JQL finds values, export those work items to ensure the data isn't needed for historical reporting or compliance.

3. Governance: If the data is no longer needed, you can proceed with deletion, but be aware that this action is permanent and cannot be undone.

Verified Documentation

• JQL Fields (Custom Fields): JQL fields | Jira Cloud | Atlassian Support

• Jira Cloud Platform API (Contexts): The Jira Cloud platform REST API

I hope this clarifies the discrepancy and helps you proceed with your audit safely!