I’m hoping I’m missing something here, but… I have an issue key - does anyone know a good way for me to find out which board it’s in? (which doesn’t involve me fetching all of the boards and looping over them ).
Hoping that there is somebody that has run into this before…
/Daniel
Hello @danielwester,
Is the originBoardId
returned by calling JSW Cloud’s Get issue a viable approach for your use case?
Cheers,
Ian
It would if I could find it, but I don’t seem to get that back (it’s not in the documentation either ).
Interesting. The only time that it is not returned for me is when the issue is not in an active sprint. Here’s a sample positive response; you can see the originBoardId
inside sprint
"fields": {
...
"sprint": {
"id": 7,
"self": "https://iangil.atlassian.net/rest/agile/1.0/sprint/7",
"state": "future",
"name": "Sample Sprint 3",
"originBoardId": 11
},
...
}
So it’s four years later, but I was wondering if this answer is still the definitive one for this question?
I don’t see an easy way to figure out which board an issue belongs to other than through brute force search through boards, and the answer below seems to work only for Sprint boards - I am looking to do this for Kanban boards.
Any advice is much appreciated.
Krishna
Hello @KrishnaK
No change that I know of.
This is principally because issues doesn’t belong to any board. Boards are ‘viewports’ into a collection of issues based on a filter, so the logical association starts at the board, so any one particular issue could be considered as being in countless boards. An issue has no ‘knowledge’ of what boards it’s in.
You can use the Search for issues endpoint to find the issue by its key and also return the value of the sprint field. If the issue is in one or more sprints, the results will also contain the boardId object, as the sprint knows what board it’s in, but if the issue isn’t in a sprint, you’re out of luck.
Thanks, yeah I suspected as much.
Curious about the special case of sprints. I am assuming that this is only available in Scrum boards right? That’s what prompted my question about the type of board.
I guess on the client side the only reliable option is to periodically poll the boards for membership and keep track of adds and deletes to each one on our end, right? We have an incremental architecture that relies on webhooks for issue updates, but it does not look like this path will help us much in keeping track of board membership.
Krishna