Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Self-approve Pull Request no longer possible


As of today it seems no longer possible to self-approve PRs. 

Event worst, a pullrequest can not have any Status that the author can set in order to mark whether the PR is open to review or what....

It is such a basic feature. We used self-approval in our workflow to indicate to the team "you now review the PR". A missing self-approval was indicating "I'm still working on this one". 

Why would you remove such a basic feature? Every other GIT tool has a Status attached to a Merge Request. 

Update: the button for self-approval is present for some PRs. But I cannot see a clear pattern.


5 answers

1 accepted

1 vote
Answer accepted
Brandon Reppert
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Dec 18, 2020

This functionality has been restored (public issue:

In our situation, we have conflicting requirements:

  1. All Pull Requests must be Approved for regulatory reasons. This should be self-evident and is immutable.
  2. Separation of duties is a desirable goal, which we understand.
  3. Because our Team Leads occasionally have to create pull requests for other people's work, they still become the approver. It is further compounded by the approver sometimes contributing a commit to the pull request to resolve issues, including merges.

The old experience provided a solution to the above. Atlassian should not be dictating our policies based for the new experience. While we understand it, you should allow Team Leads to self-approve or designate themselves as approvers.

While on infinite sized teams, you can always have complete separation of approval duties, you cannot on small teams. The Team Load/Repo Owner should always be able to approve (or should be allowed to decide whether this is possible instead of Atlassian forcing this decision upon us).

Another use case where self-approval becomes important:

Developer A is assigned an issue and creates the PR.  They are then pulled off to other work and the issue reassigned to developer B, who sometimes is one of the former reviewers.  Sometimes developer A is eventually added back as a reviewer and needs to be able to approve, even though they are the "owner" of the PR (since they created it) - though no longer the assignee of the associated Jira issue.

For this reason alone, disallowing self-approval prevents the actual reviewers from being able to mark a PR approved.  This is not just a breakage of processes people have built on top of what used to be available that aren't supported anymore.  It's a breakage of the primary workflow BB itself means to support (unless BB intends to only support the subset of cases where PR authors never become reviewers).

It's fine if there are separate author and reviewer experiences.  A critical part of the author experience is being able to indicate they approve the PR.

Or, if the author can add themselves as a reviewer, then that may solve everyone's issues as well.

Like Eliah Ninyo likes this

Good one.

Another reason, at least for us: 

we created extensive dashboards which are display information based on the return of queries to the Bitbucket REST api. Not sure how this change affects now the dashboards but I think it broke everything. There, self-approval was just displayed as any other approval.

It appears to be impossible to add a reviewer after the pull request is created. It is also not possible to add yourself when the pull request is created. This needs to be a mutable item.

Brandon Reppert
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Dec 14, 2020

@rsbeckerca You can add reviewers to a pull request after its created by selecting the expanded actions menu (the meatball just to the right of the approve button) and selecting "Edit".

We understand that there are use cases outlined here that utilize the self-approve functionality beyond the work in progress state, and so we'll keep the public issue open and look at restoring that functionality in the short-term.

I have tried to add myself to a pull request I created and was unable to do so. I can add others on the team.

Confirmed. To me somewhat inconsistent.

1 vote
Brandon Reppert
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Dec 11, 2020 • edited

@Antonius Golly this functionality was removed today as part of our updates adding the "Requests Changes" reviewer status.

This was purposefully removed as we were separating the author and reviewer experiences. It sounds like what you are requesting would best be met by having the author able to set an explicit "Work in Progress" state on the PR rather than having approvals imply that a change is no longer in progress. That change is on our radar, but I'm not sure if the timeline will be quick enough to satisfy this feature removal.

That said, thanks for letting us know your use case and we're taking a look internally at what the right path forward here is both short and long-term. We apologize for the trouble this has caused your team.


yes, correct. We are using the self-approval for indicating the ending of the WIP. That became our workflow due to a lacking PR status.

@Brandon Reppert where can I read about the "Requests Changes" reviewer status. This is not self-explanatory. If you may have the time for briefing us on this one, please...

Brandon Reppert
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Dec 12, 2020

@Antonius Golly There is some more information on the new reviewer status here:

The removal of self-approvals was intended as a part of this change, but to be truthful I believe it was an oversight on our part for how people were using self-approvals.

There are a few options here: (1) restoring the ability for authors to approve PRs, or (2) going forward with adding a "Work in Progress" state on pull requests (relevant BCLOUD ticket: We're discussing now which option to go forward with.

Meanwhile as a temporary work-around your team can still self-approve pull requests in the old pull request experience and that will display on the new pull request experience.

0 votes
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Dec 11, 2020

Hi @Antonius Golly ,

This feature should still be available. I have tried to reproduce this issue with different Bitbucket accounts, repo settings and different browsers, but I'm afraid I haven't been able to so far.

I would like to ask if you could please give us some further info, so we can figure out what might be causing this:

  1. Is every member of your team experiencing this issue? Or only specific users?
  2. Could you please let us know what browser+browser version are the affected users using? (Does the issue still occur if you try a different browser?)
  3. Does this issue occur for a specific repo only, or for all repos you have access to?
  4. Does this issue occur with older, merged PRs as well? E.g. if you check the list of merged PRs and find a merged PR created by you before yesterday, is the 'Approve' option still there or is it missing?

Kind regards,

Thanks for looking into this. The button for self-approval seems to be present for some Pull Requests. Not sure on what it depends, thought. I cannot identify a clear behavior.

@Antonius Golly i'm with you on that. 

my team also use the self approve as part of the workflow. 

but we have a different use case. 

when someone initiate a PR the reviewers add their comments and eventually approve this PR. 

sometimes the author should make some fixes and changes. so since i'm as the only one in the team who can do merge, need to see that some reviewers approved and finally the author approved the PR after finished updating what he needs. only then i'm approving the PR (without reviewing it) ad press the merge button. 

now also the merge button is not there. it is under the 3 points menu. it is also an irritating change. 

the big problem with self approval was that when i added a restriction that at least one approval is needed (not default reviewer since it is not always the same ones), the author could approve and merge without waiting for another peer to review and approve.  

Like Antonius Golly likes this
Brandon Reppert
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Dec 14, 2020

Thanks for the additional input. We believe there are some cached PR states where the self-approval was still an option, which is why it has been sometimes still displaying.

Public issue ticket for this created:

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events