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)?
There is no way to configure Stash to work the way you are suggesting. (I think it is logical that decline and approve/merge rights require the same access level.)
Perhaps, but approve (read) and merge (write) require different access levels today.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.