Remove approval of pull request when new commits are made after approval (BB-6784)

Issue #7042 resolved
Gray Gilmore
created an issue

We really like the approval feature on Pull Requests, but we hit a situation today where I had approved something, then changes were made (new commits) but my approval remained, despite me having never seen the new changes.

We think it would be great if all approvals were reset when new commits are made to a pull request, otherwise we'll simply not use the feature.


Official response

Comments (82)

  1. gugglegum

    I really can't understand how approvals functionality was implemented without this obvious thing. Without this the approval function is unusable because it misleading. And I believe this is not rocket science issue. This issue (which waiting more than 1 year) can be made of 1-3 lines of code.

  2. Alexander Ashitkin

    Please consider the case #10309 as well - "successful builds" flag should follow the same semantic. If pull request branch was moved to a new commit - 'successful build' flag should be inherited from that build or cleared if no builds data were recorded

  3. Matt Broadstone

    This is a critical feature for our current workflow. As a maintainer of a number of projects hosted on bitbucket, it's incredibly difficult for me to keep track of whether participants have accurately reviewed the pull request. There is definitely a clear mental disconnect presented with the feature as currently implemented: if I approve a pull request, I have indicated that I have read it/checked it/run the code/etc and agree that it does what it says it does, and agree with the author of the patch(es). If I approve something, and the underlaying code changes, I am now placed in an awkward situation where I've given my go-ahead but have no idea what I've signed off on anymore (the newly updated commits could COMPLETELY change the PR in the worst case).

    As the maintainer in many of these cases I become more of an "arbiter" (as I only have commit access to the master repo), and so I need to depend on my team to properly review the incoming code before merging in. The way the reviews currently work, I need to check in with the team members almost constantly to make sure that they have checked every mutation of the PR as things are being fixed based on points brought up in the discussion.

    It would ideal if two features could be added (or at least one or the other):

    • a rest api call to clear all approvals on a given pull request. If this could be done (as the administrator of a project), I could at least write a bot to watch for newly added commits/changes to existing commits on a PR and do the work myself

    • a checkbox in the project configuration to "opt-in" for automatically clearing approvals whenever any change has been made on the "source side" of a PR

  4. Alan Fregtman

    +1 New commits could introduce bugs so the pull should go back to an unapproved state.

    If you don't want to change existing behaviour, at least make it an option in the repo settings.

  5. Daniel Rech

    This is not even a feature request, it is a loophole fix.

    I would advise everyone voting for this to invite your colleagues to vote as well. As it stands, it is still too low in the voting ranking of issues.

  6. Allan Folz

    +1 As I said on #7667, before seeing this one that had more up-votes, Code Collaborator has had this feature for 5 or 6 years, at least. It's hard to take a code review tool seriously if it doesn't support such a basic work-flow as this.

  7. Brian Contario

    For those who do not know, there is an Atlassian plugin for installable versions of Bitbucket, but not the cloud version.

    See This functionality was added to the Atlassian Labs Auto-Unapprove plugin on marketplace and is not included in Stash's core offering. Please install that plugin if you'd like to automatically remove the approval of any reviewers on a push to the source branch.

    This has been available since 2013/03 !!!! Why are cloud users being punished???

  8. James Mehorter


    1. Pushing new commits to an already-approved PR should remove the approved status
    2. The previous approval should be noted in the PR activity
    3. The UI should smartly display "These edits have been pushed since approving", similar to how GitHub displays a chronological order
    4. When reviewing new changes the reviewer should not have to wade through all the code they've already reviewed/approved again.

    It would also be wildly helpful if I manually merge a PR into master on my local machine using Git (not within the PR interface in bitbucket) that Bitbucket learns about this and marks the PR as merged!!

  9. Michiel van Baak


    The activity tab already has most of the things you list.

    Also, when I merge a branch that has a PR manually to master and push it, bitbucket does mark the PR as merged.

  10. Ian Taber

    @tuchk4 thanks, it was actually more critical for the projects on our BB server. I guess we'll just have to wait for it for our cloud ones, or port them to our server install.

  11. Benjamin Echols

    Unfortunately we've hit a snag, and this feature will be delayed. I'm truly sorry for the delay - we're making an effort to communicate better, and I recognize this is frustrating.

    I'll post updates here when we have more to share.

  12. Anonymous

    @benechols Any news on this? It has been over 2 months since the last update. I don't know what snags have been hit but if the only thing that was implemented was that "Pushing new commits to an already-approved PR should remove the approved status" I would be happy.

    Obviously updates to activity and lists of what needs to be approved since the last approval would all be nice, but the crux of our organization's issues lies in approvals remaining after adding commits.

  13. Allan Folz

    "Pushing new commits to an already-approved PR should remove the approved status" I would be happy... the crux of our organization's issues lies in approvals remaining after adding commits.


    Continuous improvement beats postponed perfection.

  14. Ashley Kleynhans

    Its really disappointing that a huge company like Atlassian take more than 3 years to respond to such a simple feature request, especially when so many of their users want it so badly. It makes me want to consider switching away from every single Atlassian product that my company currenty uses because Atlassian clearly don't care about their customers at all.

  15. Michiel van Baak

    "Unfortunately we've hit a snag," what? you removed every single checkout of your repository, etc etc and have to rebuild everything by hand line by line now as all you have is a binary? Can't be anything else as there's not a single update after this for months now.

    "we're making an effort to communicate better" Another thing you guys clearly gave up on again. :(

  16. Ashley Kleynhans

    Atlassian clearly don't care about their customers whatsoever, we've been requesting to change the JIRA URL for MORE THAN 2 YEARS now and it STILL hasn't been done. We should all just abandon Atlassian products and switch to something else where they actually care about their customers and listen to what they have to say. Atlassian is by far the worst company in the entire world.

  17. Michiel van Baak

    Rick fox: this is possible if you go to the "activity" tab on a pullrequest. Search for your approval and there's a link to show the diff of the changes after your approval. I agree, a bit hidden but its there

  18. Rick Fox

    Thanks @Michiel van Baak, Yeah. it would be cool if when our approval is redacted that the green check mark icon on our picture changes to a yellow icon / hyperlink to the diff of the changes after our last approval.

  19. Frederik Dinkelaker

    We just started using pull requests on Bitbucket Cloud instead of using Crucible and I am very surprised that this has not been implemented yet. There seem to be lots of great features that have been implemented in Crucible and/or Bitbucket Server but not Bitbucket Cloud.

  20. Andrew Austin

    Is this the same as the new github premium feature just announced? "Merge checks – Another premium feature now available in a free trial allows you to enforce code reviews so you never have to waste time backing out changes."

  21. Allan Folz

    Anyone else see the email with new premium feature roll-outs? And I quote,

    • Merge checks – Another premium feature now available in a free trial allows you to enforce code reviews so you never have to waste time backing out changes.

    Frankly, I don't see how one can have a code review enforcement feature worth anything at all when the loop hole that this ticket represents is hanging wide open.

    As I said two days ago, it's like a bad Kickstarter: feature creep, charging more for stuff nobody asked for, and the basics still languish with effectively zero communication given.

  22. Frederik Dinkelaker

    Great that this has been finally implemented but a bit sad that this is considered "premium". If now we could only undo accidental declines of pull requests, but maybe that will come with the "elite" package. ;)

  23. Anonymous

    @Michiel van Baak in terms of the "See what's changed" link, this would be super useful if standard practice for your organization isn't get a code approval, rebase onto master, merge changes. That rebase throws the usefulness of that link right out the window.

  24. Troy Black

    OK, Finding that out. Do you have recommendations for places that are easy (besides Café Rio)?

    Troy Black Software Engineering Manager, Training DealerSocket, Inc.

  25. Tom Catullo

    Will this Merge Checks feature be coming to Bitbucket Server, as well? Perhaps it is in a more recent version that I have missed, but just wanted to be sure. Thanks!

  26. Tom Catullo

    He might have been referring to a plugin called "Bitbucket Server Auto Unapprove Plugin". I have not had a chance to try it out yet, but the plugin's description on the Atlassian Marketplace seems to suggest that it solves this problem.

  27. Log in to comment