Feature: Display name field mapping

[zampierilucas]

Summary

This PR introduces automatic display name field mapping for JIRA custom fields.

Motivation

For years, working with JIRA custom fields has been painful due to the cryptic field naming convention. When fetching issues, custom fields are returned as customfield_12345 instead of their meaningful display names like "Epic Link" or "Story Points". This forces developers to:

• Maintain internal mappings between field IDs and display names
• Constantly convert between cryptic IDs and readable names
• Write brittle code that breaks when field IDs change

For example, this public JIRA issue showing the custom field structure that I have to deal with:
https://issues.redhat.com/rest/api/2/issue/RHEL-12345?expand=names

Proposed solution

This PR adds transparent display name field mapping that allows both access patterns:

# Before: Only cryptic field IDs
issue.fields.customfield_10001  # Maps to "EPIC-LINK" -> "EPIC-123"

# After: Both cryptic IDs AND readable names work
issue.fields.customfield_10001  # "EPIC-LINK" -> "EPIC-123" (backwards compatible)
issue.fields.epic_link          # "EPIC-LINK" -> "EPIC-123" (new readable access)

Key consideration

• Backwards Compatible: All existing code continues to work unchanged, customfields_ are still there
• Automatic: Field mappings are automatically detected from _fields_cache
• Transparent: Display name fields are created during initial JSON parsing
• Collision Safe: Won't overwrite existing attributes

Benefits

• Developer Experience: Dramatically improves code readability and maintainability
• Self-Documenting: Field names clearly indicate their purpose
• IDE Support: Better autocomplete and intellisense
• Reduced Errors: Less chance of using wrong field IDs
• Future Proof: Adapts automatically to JIRA configuration changes

Testing

• New tests added for the new functionality and backwards compatibility

[zampierilucas]

This feels like a hack to me, but I could not find a way to access _fields_cache from resources directly, but I would love to be pointed in the 'right' way to do it.

[derekbarbosa]

adding a comment here for visibility -- this would be immensely useful in plenty of enterprise applications where custom fields are used in various automation purposes (such as webhooks, push events, etc, on various forges/CI systems). It is immensely painful to keep track of customfields at the moment, especially as their IDs can change across projects.

[studioj]

thanks a lot for the contribution, currently extension of the module though is a bit on hold until we get a grasp on the CI system and test runners . as you can see we're only testing an old version of jira datacenter. We'd really want to make sure our cloud part is up and running too before we start again with the extension with awesome functionality ...
The little time I have will be spent making this ready and indeed :-) i feel your same pain

[studioj]

adding a comment here for visibility -- this would be immensely useful in plenty of enterprise applications where custom fields are used in various automation purposes (such as webhooks, push events, etc, on various forges/CI systems). It is immensely painful to keep track of customfields at the moment, especially as their IDs can change across projects.

@derekbarbosa you're invited to do extra manual validation on this branch ... this would increase trust in the PR itself,
Thank you

[studioj]

thanks a lot for the contribution, currently extension of the module though is a bit on hold until we get a grasp on the CI system and test runners . as you can see we're only testing an old version of jira datacenter. We'd really want to make sure our cloud part is up and running too before we start again with the extension with awesome functionality ... The little time I have will be spent making this ready and indeed :-) i feel your same pain

I'm trying to get some basic cloud tests already up, maybe yours can be added

[studioj]

@zampierilucas could you also extend the examples in the docs?
please dont use epic_link as example though as it is deprecated

[zampierilucas]

Hi @studioj, thanks for the feedback, I've added both the docs and updated the "Epic links" to a new field as you suggested.
And yes, regarding the cloud test, you can use my integrations tests, just have to set up all the CI_JIRA_* env variables.

[studioj]

Hi @studioj, thanks for the feedback, I've added both the docs and updated the "Epic links" to a new field as you suggested.
And yes, regarding the cloud test, you can use my integrations tests, just have to set up all the CI_JIRA_* env variables.

I'm prepping a branch to test more on cloud, maybe a review.and.some comments can help getting it through faster

[derekbarbosa]

adding a comment here for visibility -- this would be immensely useful in plenty of enterprise applications where custom fields are used in various automation purposes (such as webhooks, push events, etc, on various forges/CI systems). It is immensely painful to keep track of customfields at the moment, especially as their IDs can change across projects.

@derekbarbosa you're invited to do extra manual validation on this branch ... this would increase trust in the PR itself, Thank you

sorry for the delay.

manual review LGTM. the self-described hack follows a similar convention to the existing _fields_cache property which returns _fields_cache_value.

trying to run the tox tests in my local env errors out, most likely due to some settings in my immutable-distro setup... will post results if I manage to get it working.