Permissions to accept/merge Pull request #1189

Closed
opened 2025-11-02 03:51:52 -06:00 by GiteaMirror · 14 comments
Owner

Originally created by @webjoel on GitHub (Oct 27, 2017).

Originally assigned to: @lafriks on GitHub.

  • Gitea version (or commit ref): 4d01eca
  • Git version: 2.7.4
  • Operating system: Linux Ubuntu 64
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

The idea is to do something like gitlab and bitbucket, where only a few users or teams can approve the pull request, and can also configure the minimum number of approvers, for example here in the company, several developers will request the pull request request for the branch "develop" and some leaders will receive a notification, review the code and approve the pull request. Example Image 1.

In the case, one or more users may disapprove the pull request, if all approve according to the minimum number the pull request can be merged. Example image 2 and 3.

This type of permission must be configured by branch, and can be in the same place where branch protection is already configured. Example image 4.

Screenshots

Image Example 1:
approvals_settings

Image Example 2:
build_status_pr

Image Example 3:
captura de tela de 2017-10-27 11-38-03

Image Example 4:
captura de tela de 2017-10-27 10-52-24

Originally created by @webjoel on GitHub (Oct 27, 2017). Originally assigned to: @lafriks on GitHub. - Gitea version (or commit ref): 4d01eca - Git version: 2.7.4 - Operating system: Linux Ubuntu 64 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description The idea is to do something like gitlab and bitbucket, where only a few users or teams can approve the pull request, and can also configure the minimum number of approvers, for example here in the company, several developers will request the pull request request for the branch "develop" and some leaders will receive a notification, review the code and approve the pull request. Example Image 1. In the case, one or more users may disapprove the pull request, if all approve according to the minimum number the pull request can be merged. Example image 2 and 3. This type of permission must be configured by branch, and can be in the same place where branch protection is already configured. Example image 4. ## Screenshots Image Example 1: ![approvals_settings](https://user-images.githubusercontent.com/1946348/32105157-4266a4c6-bb06-11e7-8ed8-4dc8f9d1f846.png) Image Example 2: <img width="870" alt="build_status_pr" src="https://user-images.githubusercontent.com/1946348/32105398-115d1c42-bb07-11e7-9594-8def22a484e9.png"> Image Example 3: ![captura de tela de 2017-10-27 11-38-03](https://user-images.githubusercontent.com/1946348/32106911-cf06e53a-bb0b-11e7-82dd-7cd11fd68585.png) Image Example 4: ![captura de tela de 2017-10-27 10-52-24](https://user-images.githubusercontent.com/1946348/32104873-11a5c7d2-bb05-11e7-8b5d-960070e2d921.png)
GiteaMirror added the type/proposaltype/feature labels 2025-11-02 03:51:52 -06:00
Author
Owner

@webjoel commented on GitHub (Oct 27, 2017):

@lafriks is working on something similar and can be merged into this issue:

"I'm working to add approval system (something like GitHub - request changes/approve) only it will be possible to define how many approvals are needed to be able to merge PR
And it will also be possible to define teams/users who can approve."

@webjoel commented on GitHub (Oct 27, 2017): @lafriks is working on something similar and can be merged into this issue: "I'm working to add approval system (something like GitHub - request changes/approve) only it will be possible to define how many approvals are needed to be able to merge PR And it will also be possible to define teams/users who can approve."
Author
Owner

@renothing commented on GitHub (Nov 1, 2017):

that's mean there should be a RBAC system first. it's not small feature

@renothing commented on GitHub (Nov 1, 2017): that's mean there should be a RBAC system first. it's not small feature
Author
Owner

@bkcsoft commented on GitHub (Nov 3, 2017):

@webjoel @lafriks Will said approval system just be "approve"/"disapprove"?

@bkcsoft commented on GitHub (Nov 3, 2017): @webjoel @lafriks Will said approval system just be "approve"/"disapprove"?
Author
Owner

@lafriks commented on GitHub (Nov 3, 2017):

@bkcsoft I'm working on approve/request changes system (something like we use LG-TM for now). Want to also integrate it with @lunny comments on code

@lafriks commented on GitHub (Nov 3, 2017): @bkcsoft I'm working on approve/request changes system (something like we use LG-TM for now). Want to also integrate it with @lunny comments on code
Author
Owner

@jogibear9988 commented on GitHub (Mar 29, 2018):

@lafriks do you still work on this? is there any test branch available?

@jogibear9988 commented on GitHub (Mar 29, 2018): @lafriks do you still work on this? is there any test branch available?
Author
Owner

@lunny commented on GitHub (Mar 29, 2018):

@jogibear9988 approve system is not ready but via https://github.com/go-gitea/gitea/pull/3689 you can indicate who can merge the pull request.

@lunny commented on GitHub (Mar 29, 2018): @jogibear9988 approve system is not ready but via https://github.com/go-gitea/gitea/pull/3689 you can indicate who can merge the pull request.
Author
Owner

@lafriks commented on GitHub (Mar 30, 2018):

@jogibear9988 I'm but I'm waiting on @lunny to finish comments on PR code to be finished

@lafriks commented on GitHub (Mar 30, 2018): @jogibear9988 I'm but I'm waiting on @lunny to finish comments on PR code to be finished
Author
Owner

@PietYorke commented on GitHub (Jun 20, 2018):

Is there any chance to get this released in the near future? Protecting a branch from "unauthorized" PRs is a must have for us.

@PietYorke commented on GitHub (Jun 20, 2018): Is there any chance to get this released in the near future? Protecting a branch from "unauthorized" PRs is a must have for us.
Author
Owner

@lunny commented on GitHub (Jun 20, 2018):

@PietYorke I think maybe #3689 could help you?

@lunny commented on GitHub (Jun 20, 2018): @PietYorke I think maybe #3689 could help you?
Author
Owner

@lafriks commented on GitHub (Jun 20, 2018):

I think this is actually resolved by #3689 isn't it?

@lafriks commented on GitHub (Jun 20, 2018): I think this is actually resolved by #3689 isn't it?
Author
Owner

@PietYorke commented on GitHub (Jun 21, 2018):

Yes, right. Thank you. We are using the gitea docker image, so it's on :latest. Would be nice to have it on a release version though.

@PietYorke commented on GitHub (Jun 21, 2018): Yes, right. Thank you. We are using the gitea docker image, so it's on :latest. Would be nice to have it on a release version though.
Author
Owner

@lafriks commented on GitHub (Jun 21, 2018):

@webjoel can this be closed as fixed?

@lafriks commented on GitHub (Jun 21, 2018): @webjoel can this be closed as fixed?
Author
Owner

@webjoel commented on GitHub (Jun 22, 2018):

@lafriks Yep! Can to close this. :)

@webjoel commented on GitHub (Jun 22, 2018): @lafriks Yep! Can to close this. :)
Author
Owner

@Cherrg commented on GitHub (Nov 7, 2018):

Hi there, #3689 is a nice feature and it will protect a branch from "unauthorized" PRs.
The feature mentioned in this feature request, would be a nice addition/extension.

So for example add an additional line 'approvers', an checkbox to enable the feature, and a number input how many approves are required.

So it will be possible to restrict merges to at least an 4 eye principle...

@Cherrg commented on GitHub (Nov 7, 2018): Hi there, #3689 is a nice feature and it will protect a branch from "unauthorized" PRs. The feature mentioned in this feature request, would be a nice addition/extension. So for example add an additional line 'approvers', an checkbox to enable the feature, and a number input how many approves are required. So it will be possible to restrict merges to at least an 4 eye principle...
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1189