You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
In our situation, we have conflicting requirements:
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.
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.
@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.
@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.
@Antonius Golly There is some more information on the new reviewer status here: https://bitbucket.org/blog/a-new-status-for-pull-requests-in-bitbucket-cloud-changes-requested
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: https://jira.atlassian.com/browse/BCLOUD-12503). 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.
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:
@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.
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: https://jira.atlassian.com/browse/BCLOUD-20665