Self-approve Pull Request no longer possible

[Antonius Golly]

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.

[Brandon Reppert · Accepted solution]

This functionality has been restored (public issue: https://jira.atlassian.com/browse/BCLOUD-20665).

[rsbeckerca]

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).

[J]

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.

[J]

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

[Antonius Golly]

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.

[rsbeckerca]

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]

@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.

[rsbeckerca]

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.

[Antonius Golly]

Confirmed. To me somewhat inconsistent.

[Brandon Reppert]

@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]

Hello, 

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.

[Antonius Golly]

@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]

@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.

[Theodora Boudale]

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,
Theodora

[Antonius Golly]

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.

[Eliah Ninyo]

@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.  

[Brandon Reppert]

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