API access to visible issues in Kanban board or column?

Jim Baker_09wfa5

My organization has a number of different Kanban teams that follow different practices, map statuses in different columns, place one or more statuses in backlog, and have different sub-queries.  I am having trouble generalizing an approach where the API result matches what is actually visible on the board.  

Explicitly duplicating each board's logic is possible but tedious, and liable to failure because teams change their rules and there's no notification mechanism.  

What I want is to be able to to specify a rapidview board ID, and get all the tickets that I would see if I inspected the board visibly, and nothing else.  Ideally, I'd love to be able to also specify a column on a board, but just getting 'tickets humans see on this board' would be a great start.  

Is it possible?

 

EDIT: I've tried rest/agile/latest/board/{rapidviewID}/issue but that's equivalent to just running the master board query.  None of the subtractive rules are applied.

Andy Heinzer

I don't think there is a single REST call you can make to keep up with the data on that board dynamically.  As you stated you can call that endpoint by itself, but Kanban boards tend to have a lot more issues matching the main board filter than usually appear there.  This is because kanban boards have a subfilter used to subtract issues that don't match that query from appearing there (such as when issues reach a version release).  Instead, I'm thinking it might be better to chain two different REST calls together to try to get all this data. 

First make a GET /rest/agile/1.0/board/{boardId}/configuration

This will at least get you back the subfilter used on a kanban board.  This is stored in the subQuery:query field value.  By default a Kanban board will usually respond with

 "subQuery": {
"query": "fixVersion in unreleasedVersions() OR fixVersion is EMPTY"

With that value, you could then call the other endpoint you mentioned of GET /rest/agile/1.0/board/{boardId}/issue

But when you do this, you would need to include that subfilter in the jql parameter that can be passed when making that REST call.   This way you could at least get back the issue currently on that kanban board that your user account has permissions to see.  If you're creating some kind of script, perhaps making this other call first can help make this data easier to obtain.

 

Note: This does not include any quick filters too that might be applied on a users personal view of the board.