• 26
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Atlassian status as of Feb 2022

      Hi everyone,

      Thanks for your feedback, passion, and advocacy for this suggestion. Please accept our apologies for allowing this issue to remain open without a clear answer from us.

      We would love to allow changing pull request authors in Bitbucket Data Center. However, we made a decision that this improvement is the wrong direction for our product. We remain committed to being an open company, whether it's with regards to feature requests or bugs in our software. 

      So what are we doing instead? We remain committed to helping software teams deliver high-quality software faster in an increasingly competitive world. We believe that great developer tools are a key element of modern software development. To that end, we've made a lot of improvements last year and are planning to work in the following areas that help with problems development teams face now:

      • Performance and scaling to support growth
      • Security and compliance features
      • Innovations around developer productivity
      • Integrations between Atlassian and other leading products

      Cheers,

      Anton Genkin
      Product Manager - Bitbucket Data Center & Server

      Copied the text of Issue BB-13100
      It should be possible to edit/change the pull request author.

      Use case: When a developer has signalled (e.g., via JIRA issue status) that a branch is ready for review but forgotten to create a pull request, the reviewer should be able to create a pull request and then change its author to the developer. Without the ability to edit, the reviewer has to pick from two or three bad options:

      • Delay the review until the developer creates a pull request (may take a few days!)
      • Create a pull request with reviewer as an author, which allows the review to proceed but screws up subsequent interaction in many ways
      • Review the branch without creating a pull request, which means review comments are going to be attached to individual branch commits (among other problems).

            [BSERV-8635] Ability to change the author of a pull request

            As said before this would be very useful when a task switches developers or the author leaves the team.

            By just editing the author all comments/tasks will remain.

            Okke Hendriks added a comment - As said before this would be very useful when a task switches developers or the author leaves the team. By just editing the author all comments/tasks will remain.

            Tadeáš Palusga added a comment - - edited

            Also upvoting for this feature. 

            If there are security reasons, the feature could be available for Admins only and its usage could be properly tracked.

            Tadeáš Palusga added a comment - - edited Also upvoting for this feature.  If there are security reasons, the feature could be available for Admins only and its usage could be properly tracked.

            Your "Not Being Considered" status said it would be reviewed in a year, and the last update you gave was February 2022. Can we get an update on this? This feature is necessary for my team for the reasons stated above.

            Forrest Jones added a comment - Your "Not Being Considered" status said it would be reviewed in a year, and the last update you gave was February 2022. Can we get an update on this? This feature is necessary for my team for the reasons stated above.

            Please reconsider this feature request, would be most helpful, for above reasons. 

            Frans Cooijmans added a comment - Please reconsider this feature request, would be most helpful, for above reasons. 

            This would be incredibly helpful to have.  A developer may leave the company with unresolved PRs, and it would be great to be able to reassign the PRs to the person who will actually finish the work.

            Nate McGrew added a comment - This would be incredibly helpful to have.  A developer may leave the company with unresolved PRs, and it would be great to be able to reassign the PRs to the person who will actually finish the work.

            Agreed, this shouldn't be a "feature" so much as a "wow I can't believe we accidentally made that non-editable"

            Richard Moore added a comment - Agreed, this shouldn't be a "feature" so much as a "wow I can't believe we accidentally made that non-editable"

            EA added a comment - - edited

            December 2022 still not fixed. We need this feature. Absolutly mandatory when dealing with many developers and some leaved the company, end of internship, end of contract, period of sickness etc. Changing the owner of the PR to go ahead and not lost time is REAL WORLD issue.

            Example : internship young dev create a PR which require work. Internship dev leave the company. Senior dev take the lead of the PR and force push some modification. He cannot change the author. Team developers will think that the internship dev still work on it and can respond to question... Which is not real.

            Performance and scaling to support growth : This issue can increase scaling.

            Security and compliance features : If this issue is a security issue, just restrict the feature of admin role or something like that.

            Innovations around developer productivity : This issue increase productivity

            EA added a comment - - edited December 2022 still not fixed. We need this feature. Absolutly mandatory when dealing with many developers and some leaved the company, end of internship, end of contract, period of sickness etc. Changing the owner of the PR to go ahead and not lost time is REAL WORLD issue. Example : internship young dev create a PR which require work. Internship dev leave the company. Senior dev take the lead of the PR and force push some modification. He cannot change the author. Team developers will think that the internship dev still work on it and can respond to question... Which is not real. Performance and scaling to support growth : This issue can increase scaling. Security and compliance features : If this issue is a security issue, just restrict the feature of admin role or something like that. Innovations around developer productivity : This issue increase productivity

            This is a very valid need and very very common in many organizations I've worked for. How did you go from that opening line showing understanding to a complete dismissal? This isn't some obscure need this is a basic task required to do my job.

            I use Jira for many clients but the dismissing tone found in many requests for features that are just huge gaping holes in usability is enough for me to recommend a switch to GitLab or others who frankly just give a damn.

            Benji Bilheimer added a comment - This is a very valid need and very very common in many organizations I've worked for. How did you go from that opening line showing understanding to a complete dismissal? This isn't some obscure need this is a basic task required to do my job. I use Jira for many clients but the dismissing tone found in many requests for features that are just huge gaping holes in usability is enough for me to recommend a switch to GitLab or others who frankly just give a damn.

            The "status" update is pretty much exactly what we do not do when dealing with users.  That is, answer with "we're going to do a bunch of things that don't meet your needs at all instead."  We have often told our clients that we're not going to do what they ask, but we're going to do something else to meet their needs instead, and in a way that we hope is better than what they were originally asking.  We don't tell them we're going to do exciting things that don't help them.

            Nice job.  I will be advocating to my employer to switch away from the Atlassian stack to something that actually does what we need it to do.  Not because you won't do this one thing, but because your response is absolutely dismissive of real-world real problems that real companies really face.

            Darin McBride added a comment - The "status" update is pretty much exactly what we do not do when dealing with users.  That is, answer with "we're going to do a bunch of things that don't meet your needs at all instead."  We have often told our clients that we're not going to do what they ask, but we're going to do something else to meet their needs instead, and in a way that we hope is better than what they were originally asking.  We don't tell them we're going to do exciting things that don't help them. Nice job.  I will be advocating to my employer to switch away from the Atlassian stack to something that actually does what we need it to do.  Not because you won't do this one thing, but because your response is absolutely dismissive of real-world real problems that real companies really face.

            ncoronado added a comment -

            This would be very useful when a task switches developers.

            ncoronado added a comment - This would be very useful when a task switches developers.

              Unassigned Unassigned
              a30bcffef444 Patrick Schaller
              Votes:
              192 Vote for this issue
              Watchers:
              91 Start watching this issue

                Created:
                Updated: