Stash: permission to decline pull request but not merge

Clifford D. Krumvieda April 27, 2015

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)?

3 answers

1 vote
Balázs Szakmáry
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 28, 2015

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.)

Clifford D. Krumvieda April 29, 2015

Perhaps, but approve (read) and merge (write) require different access levels today.

Tim Crall
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 29, 2015

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.

Clifford D. Krumvieda May 14, 2015

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.

0 votes
Clifford D. Krumvieda April 29, 2015

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.

0 votes
Roger Barnes
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 28, 2015

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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events