1. Bitbucket Website
  2. Public Issue Tracker
  3. master


Issue #4954 new

Can't revert a declined pull-request action (BB-6192)

Matthieu Perrot
created an issue

If someone of your team decline a pull request by mistake, you can't revert this operation even if your are the owner/manager of the repository with all admin rights. The alternative is to retry with a new pull-request, with the caveat of producing a spurious duplicate of the former pull-request.

In addition, it seems also strange that a pull request can be declined even if all participants have approved it !

Comments (99)

  1. Dylan Etkin

    Hi Matthieu,

    I think you are correct that we should allow you to re-open a declined PR.

    I would hesitate to not allow you to decline just because folks have approved. We are aiming for a light-weight approval system and I think that would start to dicate workflow a bit too much.



  2. Christian Walther

    Seconding the wish for a possibility to reopen declined pull requests.

    I have a couple of pull requests that I have no idea how they ended up declined (the Activity tab shows no record of anyone declining them) (may have something to do with #4900), and I’d like to reopen them.

  3. bean5

    I also find it strange that you can anonymously decline a ticket--no message is stored in the activity log about who did it!

  4. Jon Anderson

    +11 for having a confirmation dialog if you try to decline a PR when one or more reviewers have approved it. Allow, but warn :) Ah... separate feature - I'll see if it exists and create a feature request if not.

    edit Issue #8346 created for this sidekick request

  5. Tyler Ebel

    Is this scheduled to be fixed at some point ? This a huge bummer that you can't reopen a pull request. Adds redundant process and wastes time.

  6. Dan Grystad

    +1 it would be a great feature. I think its very counter intuitive that decline is a dead end and not a step in the workflow of approving a pull request.

  7. bean5

    I once removed a branch remotely and then pushed a new version, but a hook took that as a command to decline the PR. Just because it was empty for the 5 seconds I took between commands doesn't mean I wanted to decline it. I just wanted to swap out the code for the right code. (So if a branch is empty, it is still a valid PR...just with no diff to show.)

    Maybe this is another problem, but is related and was the main cause of accidental irreversible DECLINEs on PRs.

  8. David Meister

    Is this really a feature request or a massive bug in the system? This really needs to be fixed. It's been 2 years since this thread was opened (I'm willing to bet that Atlassian internally knew about this issue long before it was publicly reported) and there's still a largely undocumented button that FUBARs your PRs prominent in the UI.

  9. bean5

    No idea...could the creator of this request please change it to a non-minor priority? I don't think it should be difficult at all to be able to flip a boolean in the database (declined/not).

  10. bean5

    I agree. But the fix should be fairly intuitive.

    On a positive note, it looks like the decline button, even if accidentally hit will request the user to provide a reason to decline, which mitigates the possibility of accidentally pushing the button. I don't have much of a problem with the button itself. I have a problem with the fact that the PR was automatically declined when the branch was removed. Now that I know more about BB, I wonder if there was a hook involved. I'm going to look into that...

  11. bean5

    Yeah, looks like there is a "hook" involved that can't be disabled. The PR realizes that there is nothing to commit and determines that that means "decline". Git can revert reverts, so it makes sense to be able to undo a decline. I vote for the ability to reverse a decline.

  12. Rick Cuddy

    +1 etc etc

    Really want a workflow based around declining because of problems that can and should be fixed, to replicate workflows such as Phabricator where approval indicates request can be merged, where decline indicates work remains to be done.

  13. Victor Engel

    +1 I also just declined a PR and can't reverse the decline. Not good. I declined because of a perceived problem. When the problem is resolved, the PR should be able to proceed.

  14. Anonymous

    This was first brought up as an issue 3 years ago. How long does it take Atlassian to implement features? Yes, don't dictate workflow, but also do not tie our hands. I have several comments to create tasks from a pull request that has already been declined. In not allowing us to re-open it, you've already dictated workflow.

  15. bean5

    Should we update this to be a "bug" rather than new feature? I really thought that I'd be able to un-decline. Was anyone else thrown off by this?

  16. bean5

    I was able to "recover" using the work-around of making another PR. But since I call that a work-around, I guess I agree. This is a bug in my book.

  17. Tri Nguyen

    Please vote and not comment a "+1". You can also follow this issue by watching it. This will avoid spamming all existing watchers with the noise. Perhaps we should say this explicitly in the description of the issue.

  18. Tim Ahrens

    Try finding documentation on what the "Decline" button does?? Does it mean I declined to do the review because I don't have time, OR does it mean I think the code cannot be released without the corrections I have suggested?? A simple mouseover tool tip would go a long way to clarifying this. So, I am very reluctant to click it not knowing what will happen when I do click Decline. Can someone please tell me?

  19. bean5

    Tim Ahrens Currently it marks the pull request as declined. If I recall correctly it will ask you to fill in a reason why you are declining it. It is currently irreversible (hence this ticket). I only decline a branch if a ticket is going to be closed or if we want to totally restart the branch, but leave the ticket open. This happens if we find we went down the wrong path for a ticket, but for some reason want to keep a history of the first attempt. This is only necessary if the pull request has a lot of history on it. If it doesn't have comments, I'd suggest just replacing the branch with a new set of commits. (Be careful when replacing branches, though. Sometimes in the process of rebasing a branch the remote one is removed, which can automatically trigger the decline action.)

  20. John Schank

    Agreed, not know what it does is the worst. There is an approve button, so logically I assumed declined meant that I reviewed it, but did not approve. Which, BTW, would be a good button to have.

  21. bean5

    If you don't approve, I think the idea is that you are using JIRA and therefore take a ticket out of review stage and put it back into "Dev" or something like that. If you have reviewed, the developer(s) know it because of the state change there and because you left a comment which has your name listed as the commenter. But having an official "Done reviewing this round" might be a good way to let the developer(s) know that you are done and it is basically ready for them--at least in relation to your comments. If there are multiple reviewers, it might still be in review.

  22. bean5

    Jayd Lawrence If Stash has this and BB doesn't, I think that would be a bug as one expects Stash and BB to only differ in features that set them apart. Is revert decline meant to be a differing feature?? I hope not. Matthieu Perrot do you know? If so, you may want to refile this under bug rather than as proposal.

  23. Stephen Sykes

    OMG still not resolved? Just accidentally declined (not fully understanding Atlassian's workflow here - and decline seems to be usable as "not until issues are addressed" versus "NEVER"). Now we're stuck.

  24. will_murphy

    Just declined a colleague's pull request as a joke and now he has to create another. Maybe the moral of the story is that I shouldn't make jokes....

  25. bean5

    Dylan Etkin do you mean to say that a workflow that includes an 'un-decline' doesn't make sense? It happens in real life. Sometimes something is declined purely because of timing, but when the moment is right, is re-approved. That is how some technology works.

    Un-decline is a natural process, doesn't dictate workflow any more than the person choosing to push the button corresponding to it.

  26. Joshua Swanson

    bean5 No, check it again - what he said was that an un-decline makes sense, but it doesn't make sense to prevent declining because someone has approved it - which I completely agree with.

    Still, the key point here is that it's been four years with no action on this... and we really need to see some!

  27. Log in to comment