Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-8226

Cross-repository pull requests prevent deletion of personal forks in some cases

      As a Stash/Bitbucket Server User I want to be able to delete my personal fork even though I have a pull request (open OR declined) to an upstream repo to which I no longer have permission to access.

      HTR

      1. Fork a repo to your personal project.
      2. Open a PR from your fork to the upstream repo.
      3. Have a user with Project Admin or higher perms remove your permission to the upstream repo.
      4. Push another change to your personal fork that would update the PR (the PR shouldn't be visible to you anymore at this point).
      5. Delete your fork.

      Expected Result

      My forked repo is deleted successfully.

      Actual Result

      Fork deletion fails and an error modal is displayed:

      Repository deletion was canceled.
      Pull requests involving ~DROHAN/blues could not be cleaned up. The repository may not be delete

            [BSERV-8226] Cross-repository pull requests prevent deletion of personal forks in some cases

            When personal forks first shipped in Stash 2.4.0, it was possible to delete a personal fork (or any other fork) regardless of what pull requests existed (regardless of their state). It appears, during the 3.x changes necessary to support clustered installations, that ability was regressed.

            Given that this is a regression of behavior that used to work, I've reclassified this as a bug, which I consider it to be.

            Best regards,
            Bryan Turner
            Atlassian Bitbucket

            Bryan Turner (Inactive) added a comment - When personal forks first shipped in Stash 2.4.0, it was possible to delete a personal fork (or any other fork) regardless of what pull requests existed (regardless of their state). It appears, during the 3.x changes necessary to support clustered installations, that ability was regressed. Given that this is a regression of behavior that used to work, I've reclassified this as a bug, which I consider it to be. Best regards, Bryan Turner Atlassian Bitbucket

            Hendrik (Inactive) added a comment - - edited

            Ok, so here is the trick. I've added to the HTR what is now Step 4: Push another change to your personal fork after permissions to the upstream repo have been removed. This will allow you to reproduce the issue, even on the latest version of Bitbucket.

            The reason behind is that when you attempt to delete a fork, Bitbucket will ensure for each unmerged PR that it is up-to-date and only then unlink it from the to-be-deleted repo. The particular way how it accesses the PR entity in this case is unfortunately no longer permitted with the permissions revoked.

            Note that simply viewing the PR in the upstream repo as a user with sufficient permissions will trigger (successfully) a similar update. With your PR all up-to-date again, you will then be able to delete your personal fork. (I would not consider this an acceptable real-world workaround though.)

            Hendrik (Inactive) added a comment - - edited Ok, so here is the trick. I've added to the HTR what is now Step 4: Push another change to your personal fork after permissions to the upstream repo have been removed. This will allow you to reproduce the issue, even on the latest version of Bitbucket. The reason behind is that when you attempt to delete a fork, Bitbucket will ensure for each unmerged PR that it is up-to-date and only then unlink it from the to-be-deleted repo. The particular way how it accesses the PR entity in this case is unfortunately no longer permitted with the permissions revoked. Note that simply viewing the PR in the upstream repo as a user with sufficient permissions will trigger (successfully) a similar update. With your PR all up-to-date again, you will then be able to delete your personal fork. (I would not consider this an acceptable real-world workaround though.)

            Daniel R added a comment -

            hschnepel I tested with 4.10 and could not reproduce so I tried again with 4.1.0 and was able to reproduce it on a vanilla instance. I'm happy to provide details or do a screen share to discuss further. 

            Daniel R added a comment - hschnepel I tested with 4.10 and could not reproduce so I tried again with 4.1.0 and was able to reproduce it on a vanilla instance. I'm happy to provide details or do a screen share to discuss further. 

            I tried to reproduce this issue on 3.9.2, 4.1.0, and latest, but failed to do so; i.e. everything worked as expected. Maybe the problem is caused by some additional detail that is missing from this report? If you would like to work on figuring this out, please let us know; until then I'm closing this ticket.

            Hendrik (Inactive) added a comment - I tried to reproduce this issue on 3.9.2, 4.1.0, and latest, but failed to do so; i.e. everything worked as expected. Maybe the problem is caused by some additional detail that is missing from this report? If you would like to work on figuring this out, please let us know; until then I'm closing this ticket.

              hschnepel Hendrik (Inactive)
              drohan Daniel R
              Affected customers:
              3 This affects my team
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: