Why are boards instead of jira projects selectable in a jira data scope?

[pogopaule]

My question is the headline. I am confused why boards were chosen instead of projects.
Boards are defined by filters on issues, hence they are only views on a subset of all jira issues. If a jira issue is not selected by any board, DevLake won't be able to ingest it.
To me it would make more sense to define the data scope for jira based on jira projects.

[klesh]

1. sprints are bound to boards which is essential for some metrics IIRC
2. boards has filters so users have control over what to be synced

[gsaivenkateshzs]

we have a usecase where we wanted to collect issue details of all jira projects across org. each project have their own boards with their own configuration (column management - which hides some of the tickets). for us to collect all issue details from all projects, we have to create another jira board for each project just for this usecase. @klesh i think it's better to ask users to give a jql instead of board. any thoughts?

[gsaivenkateshzs]

or we can give both if board is needed for some metrics

[klesh]

@gsaivenkateshzs In that case, you may create a board to include all those issues.

[gsaivenkateshzs]

yeah i am doing that as workaround. but it won't work as long time solution as there might be new issue status types and we need to map those statuses to the board. i feel it's better to ask JQL or Jira filter as alternative to board. i don't see any benefit of using boards instead of jql other than some board related metrics

[gsaivenkateshzs]

jql or jira filter makes things very simple

[gsaivenkateshzs]

if you resonate with me, maybe i can contribute to this (can't guarantee though , need to check with my employer).

[klesh]

I thought boards are essentially jql or jira filter, we may define a board with a jira filter to include all issues from all projects, and then collect from it, and we may keep doing so without changing the board definition. This was what I had in mind.
But, seems like I have misunderstood the situation.
Could you help me understand what I missed?

[gsaivenkateshzs]

yeah you are correct. but there is one issue with the boards, there is something called as column management where you need to map statuses to columns. if there are new status types, we need to map them to columns. otherwise the issues with those status types will not shown in the board.

[gsaivenkateshzs]

https://support.atlassian.com/jira-service-management-cloud/docs/manage-board-columns-and-statuses/

[GollaSaiVenkatesh]

any thoughts on this @klesh ?

[gsaivenkateshzs]

also we want to capture data of a custom field in jira. is there a way to get that data ?

[klesh]

any thoughts on this @klesh ?

No, I am not familiar with the column management, even after reading the doc I still don't understand why project can solve the problem.

also we want to capture data of a custom field in jira. is there a way to get that data ?

This may help: https://devlake.apache.org/docs/Plugins/customize

[gsaivenkateshzs]

Thanks for pointing me to customize plugin. I saw this eariler but forgot it.

[gsaivenkateshzs]

@klesh
Let me try to explain the problem with Jira boards. Jira boards are view of issues where you need to configure what all issues you need (through JQL) and these are shown in the rows and there are columns in jira boards which represent status of issues. to keep the things organized and simple, Jira asks you to configure which statuses should map to a particular column in the board. And if particular status is not mapped to any of the columns, then those issues won't be shown in the board.

Here the problem comes, since there is manual configuration required for mapping status to column. some teams may not configure them properly (especially when they introduce more statuses to their team’s working process).

May i know reason why boards are selected for this usecase of getting issues other than some board related metrics?