[Bug][Jira/DORA] Extra JQL does not isolate projects sharing the same Jira board

Start by tracing issue_collector.go and task_data.go, then follow project_mapping and board_issues into incident_from_issue_generator.go. Compare how rendered Extra JQL and shared-board state are handled across collection and DORA conversion. Done means an end-to-end regression test with two projects sharing a Jira board keeps each project's issues and incidents isolated.

Search before asking

• I searched the existing issues and found no report covering this specific isolation problem.

Related work:

• #8955 describes the original requirement for component-based scoping of shared Jira boards.
• #8972 added Extra JQL support.
• #9035 added {{.ProjectName}} support to Extra JQL.
• #8198 and #6768 describe related shared-board and cross-project data problems, but not this behavior.

What happened

Two DevLake projects use the same Jira connection and board. Jira components identify the deployable units, and both projects share this scope configuration:

component = "{{.ProjectName}}"

For a project named service-alpha, DevLake renders and executes the expected query:

filter = 12345 AND (component = "service-alpha")
AND updated >= '2026/09/18 12:45'
ORDER BY created ASC

The observed incremental request completed successfully, but the extractor found zero new raw issue rows and convertIssues processed zero issues. Nevertheless, the subsequent DORA ConvertIssuesToIncidents subtask converted 13 existing issues into incidents for service-alpha. Those issues included components belonging to other deployable units.

A direct Jira query returned zero matching bugs for service-alpha, while the shared board contained hundreds of bugs overall. This confirms that the unrelated incidents were not returned by the rendered Extra JQL query.

The behavior appears to result from collection being filtered by project name while persistence and DORA enrichment remain scoped only by the shared board:

1. Jira raw-data parameters and collector state are identified by (connectionId, boardId) and do not include projectName or the rendered Extra JQL.
2. Domain membership is stored as board_issues(board_id, issue_id).
3. Each DevLake project maps to the same domain board through project_mapping.
4. ConvertIssuesToIncidents selects incident-classified issues through project_mapping -> board_issues -> issues, without applying the project's Extra JQL or another project-specific issue predicate.

As a result, issues collected by one project can be treated as incidents of another project when both projects share the same Jira connection and board.

Relevant code:

• issue_collector.go
• task_data.go
• incident_from_issue_generator.go

What do you expect to happen

When Extra JQL is evaluated with {{.ProjectName}}, the resulting issue set should remain isolated for that DevLake project throughout collection, persistence, project mapping, and DORA enrichment.

An issue excluded by a project's rendered Extra JQL must not appear as an issue or incident for that project merely because another project collected it from the same Jira board.

How to reproduce

1. Create one Jira connection and one Jira board containing recently updated bugs for at least two components, for example service-alpha and service-beta.
2. Create two DevLake projects named service-alpha and service-beta.
3. Map the same Jira connection and board to both projects.
4. Assign both scopes the same scope configuration containing:

   component = "{{.ProjectName}}"
   

5. Configure a Jira issue type as the DevLake INCIDENT standard type (for example, Bug) so the DORA incident-conversion path is exercised.
6. Run the pipeline for service-alpha, update a service-beta bug if needed to place it inside the next incremental window, and then run the pipeline for service-beta so issues for both components become associated with the shared board.
7. Run service-alpha incrementally again, with no matching Jira issues updated during the incremental window.
8. Confirm that collectIssues logs the correctly rendered component = "service-alpha" clause and that extractIssues/convertIssues process zero issues.
9. Observe that ConvertIssuesToIncidents still processes incidents belonging to service-beta or other components associated with the shared board.

The following query illustrates the set currently used by DORA enrichment:

SELECT i.issue_key, i.component, bi.board_id
FROM issues i
JOIN board_issues bi ON bi.issue_id = i.id
JOIN project_mapping pm ON pm.row_id = bi.board_id
WHERE i.type = 'INCIDENT'
  AND pm.project_name = 'service-alpha'
  AND pm.table = 'boards';

Rows with components other than service-alpha are returned.

Anything else

This is not a template-rendering failure: the logs show that {{.ProjectName}} is rendered and included in Jira's effective JQL.

The available configuration workarounds are to create a distinct Jira board or a distinct DevLake Jira connection for every deployable unit. Both defeat much of the scalability benefit intended by #8955 and #9035.

A complete fix likely requires a project-specific logical scope for filtered Jira boards, rather than sharing collector state and board_issues solely by (connectionId, boardId). An end-to-end regression test should cover two DevLake projects using different rendered Extra JQL values against the same physical Jira board, followed by DORA incident conversion.

Version

v1.0.3-beta17@8fe26f4

Are you willing to submit PR?

• Yes, I am willing to submit a PR.

Code of Conduct

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