Unapproved Pull Requests Notification shows an incorrect count

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

Users see a notification for unapproved Pull Requests; however, if they navigate to their inbox there will be no results:

Diagnosis

Steps to reproduce:

  1. Create a pull request in Repo1 and add UserA as a reviewer.
    1. PR inbox shows one pull request.
  2. Create a pull request in Repo2 and add UserA as a reviewer.
    1. PR inbox now shows two pull requests.
  3. Remove UserA from the permissions in Repo2 so they no longer have access to it.
  4. Inbox will show a badge of two pull requests but clicking on the badge only shows one.

Cause

The count of Pull Requests showing up on the inbox for a user also includes Pull Requests that the user does not have access to. This creates an inconsistent view when the user clicks on the pull request inbox and sees fewer pull requests than what the count shows.

The REST API endpoints that are available will return the correct results; however, the UI performs a quick check without looking at permissions, which can lead to the mismatch being noticed. This was implemented for performance optimisation purposes.

This can be reproduced by removing a users permissions from a repository after they've been added to a project.

This particular issue was initially reported on BSERV-7123 - Pull request inbox count includes PRs that the user does not have permission to 

 Solution

Run the following SQL query to verify all open Pull Requests assigned to the user being impacted:

select  
    format('https://<BITBUCKET_BASE_URL>/projects/%s/repos/%s/pull-requests/%s/overview', prj.project_key,r.slug,pr.scoped_id),
    pr.pr_state,
    u.slug,
    pr.from_branch_name,
    pr.to_branch_name,
    r.slug,
    prj.project_key,
    prj.name,
    pr.created_timestamp
 from sta_pull_request pr
join  sta_pr_participant p
on pr.id = p.pr_id
join sta_normal_user u
on p.user_id=u.user_id
 join repository r
            on pr.from_repository_id=r.id
        join project prj
            on r.project_id=prj.id
where u.slug = 'username' --where username is the login ID of the user in question
and pr.pr_state = '0'
order by pr.created_timestamp desc

(warning) Your DBA may need to adjust the query for your specific database type.

After obtaining the results, you will need to manually verify if the user has permissions on the Project or Repository for these Pull Requests, and remove the user from the Approvers list for the ones they do not have access to.

Last modified on Apr 27, 2021

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.