When the RequiredBuildsMergeCheck runs, it verifies the LICENSED_USER for the calling user. For general operations, that check works because most of the time pull requests are being merged by users, who must be licensed in order to authenticate and use the UI.

As an example of where that LICENSED_USER check incorrectly fails, though, multiple third-party add-ons exist which trigger a PullRequestService.canMerge check in response to pull request rescopes. Here are some examples:

• Pull Request Notifier for Bitbucket
• Post Webhooks for Bitbucket
• Workzone: PullRequest Workflow

PullRequestService.canMerge has its own permission check to verify that the calling context can "see" the pull request in question, and, in all the linked issues, that check has passed successfully. However, when RequiredBuildsMergeCheck calls DefaultBuildStatusService.getSummary, the validateUser check verifies LICENSED_USER on top of the permission checks performed by canMerge.

That means, for example, calling PullRequestService.canMerge as a service user (used by "bots", but also used by SSH access keys), the LICENSED_USER check fails. This leads to add-on developers (often incorrectly) escalating permissions to ensure the check won't fail.

When build stats are retrieved in order to enforce the required builds check, it should not require LICENSED_USER permission; it should only require that the calling user has access to the pull request.