It appears that a user can decline a pull request if and only if he/she can merge it (i.e., has write access to its target). Instead, is it possible to configure stash such that a user can decline a pull request if and only if he/she can approve it (i.e., has read access)?
Approve is just a "thumbs up" - it doesn't actually do anything. Merge affects the codebase so obviously requires write. But decline does more than just vote "thumbs down" (there is no equivalent for that) - it disposes of the Pull Request, so thus it requires the higher degree of permission.
I agree in some workflows it is necessary for 'decline' to have a different (probably higher) permission level than 'approve'. Similarly, I believe there are valid workflows where 'decline' needs to have a different (probably lower) permission level than 'merge'. This is because someone with merge privileges not only determines what can be merged to the target branch, but also when and in what order PRs are pulled. There are several ways to implement my request, and I'm not advocating for a particular one. E.g.: * Add a permission level. * Add a toggle that determines whether 'read' has 'decline' privileges or not. * Separate privileges ('can view PRs', 'can decline PRs', 'can merge PRs', etc.) from roles ('reader', 'branch captain', 'admin', etc.) and provide a mechanism to map privileges to roles.
Hi Clifford, Would you mind describing your use case in more detail? To explain the thinking behind how it works currently... the intention is that a "gatekeeper" (ie someone with write access to the target) makes a one-time decision whether to merge or decline following the code review process. The reviewer-level process of 1 or more people approving currently has no opposite action (ie disapproving), although there do exist plugins to introduce a "block" concept on marketplace.atassian.com - https://marketplace.atlassian.com/search?q=block+pull+request A reviewer who does not yet approve should just leave the approve button unpressed until such time as their feedback is addressed, or it is agreed that the person with merge responsibility should decline.
In our workflow, the gatekeeper (who as you say makes the one-time decline/!decline decision) is not the person who is responsible for controlling which fixes go in when and in which order. Only the latter needs write privileges to the branch. Related to this, the gatekeeper varies by the area of the code being touched, so we have multiple gatekeepers and do not want to give all of them write privs.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot