Jira Software Cloud REST API | Getting Board Configuration as Administrator

Jira Development Jira Cloud
1

Hello everyone,

first giving some context here:

From an administrator point of view, getting an overview about boards and their integrity isn’t the easiest task. To mitigate that problem, I’ve been gathering data from various endpoints to create an overview about boards, their configuration with the corresponding details (e.g. estimation statistic, rank field, etc.) and all details of the filter itself (e.g. owner, isActive, JQL, etc.). With that I’ll can check if everything is fine or if there areas that need to be updated (e.g. assignee in an underlying filter doesn’t exist anymore, a project component was renamed, etc.) or can be deleted (e.g. the underlying filter is private, the owner is inactive, so nobody can work with the board and I’ll can delete it).

And I’ll do the same for Jira Data Center trough Java APIs. Adopting everything to Forge becomes a challenge looking at runtime because fetch all boards, for each board fetch the underlying configuration to get the filterId, with the filterId fetch the details from the filter.
Within a small instance with ~250 boards, this will end in ~500 individual REST API calls.
But that’s another story.

So coming to the problem itself:

  • :white_check_mark: Get all boards API has to ability to add includePrivate=true to get all boards.
    Remarks: That a private boards doesn’t have a name is weird, but it looks also weird when an administrator goes to https://company.atlassian.net/jira/boars directly.
    Getting the name for a private board would can under some circumstances work when using api.asApp().requestJira(...) instead of api.asUser().requestJira(...).
    Here some response:
GET https://customer-staging.atlassian.net/rest/agile/1.0/board?includePrivate=true&maxResults=50&startAt=50
============================================================================================================
{
  "maxResults": 50,
  "startAt": 50,
  "total": 203,
  "isLast": false,
  "values": [
    {
      "id": 251,
      "self": "https://customer-staging.atlassian.net/rest/agile/1.0/board/251",
      "name": "Team #1",
      "type": "kanban"
    },
    {
      "id": 2,
      "self": "https://customer-staging.atlassian.net/rest/agile/1.0/board/2",
      "isPrivate": true
    },
    {
      "id": 34,
      "self": "https://customer-staging.atlassian.net/rest/agile/1.0/board/34",
      "location": {
        "projectId": 10109,
        "displayName": "Customer Homepage (ABC)",
        "projectName": "Customer Homepage",
        "projectKey": "ABC",
        "projectTypeKey": "software",
        "avatarURI": "https://customer-staging.atlassian.net/rest/api/2/universal_avatar/view/type/project/avatar/10422?size=small",
        "name": "Customer Homepage (ABC)"
      },
      "isPrivate": true
    }
  ]
}
  • :x: Get configuration API
    Remarks: The endpoint doesn’t have a parameter like includePrivate or overrideSharePermissions which means api.asUser().requestJira(route`/rest/agile/1.0/board/{boardId}/configuration`) will fail and don’t return the configuration of the board. Playing around with api.asApp().requestJira(route`/rest/agile/1.0/board/{boardId}/configuration`) instead would return the configuration for the board with "id": 2 but not for board with "id": 34.
    Digging into the data, the underlying filter for id 2 has a project share permission whole id 34 has a group share permission. So it behaves not the same here. But the root cause might be also something else.
    Also to proceed with my report that I’ll want to create, I’ll need to exclude everything that is private because from a board perspective I’ll can’t see if it’s shared with a group or project. Otherwise I would be able to include also a few private boards. Just looking at an instance of mine… ~60 public boards while having ~260 boards in total. Means for me as an administrator 75% are not visible to identify problems without touching every filter share permission.
  • :white_check_mark: Get filter has the ability to add overrideSharePermissions=true to get all filters include everything that is restricted.

To summarize the Get configuration API would require some improvements so that that administrators can really dig into their instances and administrate.

Did I’ll miss anything here? Can this limitation on the configuration API be removed or is there another way to solve the problem? For me it doesn’t make sense to restrict it like that.

Kind Regards