christoph-mueller-sda-se opened a new issue, #9151: URL: https://github.com/apache/devlake/issues/9151
<!-- Issue title: [Bug][Jira/DORA] Extra JQL does not isolate projects sharing the same Jira board --> ## Search before asking - [x] I searched the existing issues and found no report covering this specific isolation problem. Related work: - [#8955](https://github.com/apache/devlake/issues/8955) describes the original requirement for component-based scoping of shared Jira boards. - [#8972](https://github.com/apache/devlake/pull/8972) added Extra JQL support. - [#9035](https://github.com/apache/devlake/pull/9035) added `{{.ProjectName}}` support to Extra JQL. - [#8198](https://github.com/apache/devlake/issues/8198) and [#6768](https://github.com/apache/devlake/issues/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: ```jql component = "{{.ProjectName}}" ``` For a project named `service-alpha`, DevLake renders and executes the expected query: ```text 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`](https://github.com/apache/devlake/blob/8fe26f46c83a83864249cd0a4c228606e3960aec/backend/plugins/jira/tasks/issue_collector.go) - [`task_data.go`](https://github.com/apache/devlake/blob/8fe26f46c83a83864249cd0a4c228606e3960aec/backend/plugins/jira/tasks/task_data.go) - [`incident_from_issue_generator.go`](https://github.com/apache/devlake/blob/8fe26f46c83a83864249cd0a4c228606e3960aec/backend/plugins/dora/tasks/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: ```jql 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: ```sql 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 - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
