[Feature][Jira] Extend support for type mapping

[doomspork]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Use case

As a solutions architect I want to use DevLake to measure DORA and other metrics within established organizations who may be unwilling, or unable, to change their current Jira setups to conform to DevLake's limited type mappings.

Description

In our large multi-vendor environment, DevLake's current Jira plugin has a limitation that prevents us from fully adopting it for DORA metrics. Specifically, we need to distinguish between Bug and Incident issues that share the same Jira type but are differentiated by labels (e.g., severity/p0). The existing plugin doesn't support this label-based differentiation, and the workaround proposed in #4217 doesn't scale for enterprise use cases.

After evaluating various approaches to implement ticket type + label combination mapping while maintaining backwards compatibility, I propose introducing GopherLua for custom user scripting. I have developed a working proof of concept that demonstrates this approach. The solution allows DevLake to handle sophisticated issue mapping rules while maintaining the simplicity of the current system for basic use cases. An example script I am using:

function getStandardType(issueType, status, labels)
    for i, label in ipairs(labels) do
        if issueType == "Bug" and label == "p0" then
            return "INCIDENT"
        end
    end

    -- Fall back to previous logic
    if issueType == "Epic" then
        return "REQUIREMENT"
    elseif issueType == "Story" then
        return "REQUIREMENT"
    elseif issueType == "Bug" then
        return "BUG"
    end

    return string.upper(issueType)
end

While the introduction of GopherLua is a significant change, I believe the benefits of this approach outweigh the negatives:

• Enables enterprise-scale DORA metric collection in complex environments
• Provides flexibility for organizations with custom Jira workflows
• Maintains simplicity for basic use cases
• Future-proofs the plugin for additional mapping scenarios
• Adoption by other plugins further extends DevLake's adaptability.

Related issues

#4217

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[doomspork]

I wanted to add since I didn't specifically mention so in my issue: If there's a more suitable approach to solving this with backwards compatibility, happy to work with the Apache DevLake team to identify the alternative and implement it.