User in team which has read perm to issues can create issue in a private org repo #10298

New Issue

GiteaMirror · 2025-11-02T09:03:34-06:00

GiteaMirror commented

2025-11-02 09:03:34 -06:00

Originally created by @yp05327 on GitHub (Feb 19, 2023).

Description

team permission settings:

private org and private repo:

It shows that the user in this team only have read permission to issues

But the user in this team can create issues in this repo

PR can not be created, and this is right.

Gitea Version

1.19.0+dev-403-gb6b8feb3d

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

gitea.com

Database

None

Originally created by @yp05327 on GitHub (Feb 19, 2023). ### Description team permission settings: ![image](https://user-images.githubusercontent.com/18380374/219947021-fe74bfdf-f58d-48d6-b6b5-0cca7946637f.png) private org and private repo: ![image](https://user-images.githubusercontent.com/18380374/219947127-0feb47d2-c5c3-43c7-bf57-86ac3825d2b9.png) It shows that the user in this team only have read permission to issues ![image](https://user-images.githubusercontent.com/18380374/219947033-0c7e8627-665b-462c-a2e5-b30e9d25eea3.png) But the user in this team can create issues in this repo ![image](https://user-images.githubusercontent.com/18380374/219947058-a665eda7-2ee8-42e0-ae3d-8e92fb1c2d53.png) PR can not be created, and this is right. ![image](https://user-images.githubusercontent.com/18380374/219947077-9300b927-cc98-45ae-b871-8f181c4a1fab.png) ### Gitea Version 1.19.0+dev-403-gb6b8feb3d ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? gitea.com ### Database None

GiteaMirror added the issue/needs-feedback issue/not-a-bug labels 2025-11-02 09:03:34 -06:00

GiteaMirror closed this issue

2025-11-02 09:03:34 -06:00

GiteaMirror commented

2025-11-02 09:03:35 -06:00

@lunny commented on GitHub (Feb 19, 2023):

This is by design.

@lunny commented on GitHub (Feb 19, 2023): This is by design.

GiteaMirror commented

2025-11-02 09:03:35 -06:00

@delvh commented on GitHub (Feb 19, 2023):

I mean…
I can understand that if you declare write permissions as editing issues that are not their own.
Intuitively, I agree with @yp05327.
However, I can also see why teams with read permission should still be able to create (but not edit) issues.

@delvh commented on GitHub (Feb 19, 2023): I mean… I can understand that if you declare `write permissions` as editing issues that are not their own. Intuitively, I agree with @yp05327. However, I can also see why teams with `read` permission should still be able to create (but not edit) issues.

GiteaMirror commented

2025-11-02 09:03:35 -06:00

@yp05327 commented on GitHub (Feb 20, 2023):

It seems that the permission controll and the definitions are confusion and hard to understand.

I tested some of them in gitea.com as following: (with a private repo in a private org and the repo is added to the team, so the permissions should be controlled by team permission settings I think ):

Issues:

Actions	No Access	Read	Write
Read	x	○	○
Create	x	○	○
Edit	x	-(only their own)	○

Nothing strange but teams with Read permission can Create issues. This is what I mentioned in this issue.

PR:

Actions	No Access	Read	Write
Read	x	○	○
Create	x	-(depends on Code)	-(depends on Code)
Edit	x	-(only their own)	○
Code Review(Approve)	x	○	○

The description of PR permission is:

Enable pull requests and code reviews.

But Create a PR depends on Code permission actually, and Approve a PR is partly depends on PR permission.
And teams with No Access permission of Code and Read permission of PR can also Review the changes in this PR and Approve it.

I don't know whether this is the correct design, but it looks confusion.

@delvh

However, I can also see why teams with read permission should still be able to create (but not edit) issues.

So is it possible to separate Create and Edit from Write in some units.
Create means you can create a new issue/PR/wiki/projects/package and edit your own.
Edit means you can edit all the existed issue/PR/wiki/projects/package (and codereview?)
Code is special, maybe can only have Read and Write?

@yp05327 commented on GitHub (Feb 20, 2023): It seems that the permission controll and the definitions are confusion and hard to understand. ---- I tested some of them in gitea.com as following: (with a private repo in a private org and the repo is added to the team, so the permissions should be controlled by team permission settings I think ): Issues: | Actions | No Access | Read | Write | | ---- | ---- | ---- | ---- | | Read | x | ○ | ○ | | Create | x | ○ | ○ | | Edit | x | -(only their own) | ○ | Nothing strange but teams with `Read` permission can `Create` issues. This is what I mentioned in this issue. PR: | Actions | No Access | Read | Write | | ---- | ---- | ---- | ---- | | Read | x | ○ | ○ | | Create | x | -(depends on Code) | -(depends on Code) | | Edit | x | -(only their own) | ○ | | Code Review(Approve) | x | ○ | ○ | The description of PR permission is: > Enable pull requests and code reviews. But `Create` a PR depends on Code permission actually, and `Approve` a PR is partly depends on PR permission. And teams with `No Access` permission of Code and `Read` permission of PR can also `Review` the changes in this PR and `Approve` it. ---- I don't know whether this is the correct design, but it looks confusion. @delvh > However, I can also see why teams with read permission should still be able to create (but not edit) issues. So is it possible to separate `Create` and `Edit` from `Write` in some units. `Create` means you can create a new issue/PR/wiki/projects/package and edit your own. `Edit` means you can edit all the existed issue/PR/wiki/projects/package (and codereview?) `Code` is special, maybe can only have `Read` and `Write`?

GiteaMirror commented

2025-11-02 09:03:35 -06:00

@lunny commented on GitHub (Jul 27, 2023):

The design is the same as GH, I think it's not a bug.

@lunny commented on GitHub (Jul 27, 2023): The design is the same as GH, I think it's not a bug.

GiteaMirror commented

2025-11-02 09:03:36 -06:00

@yp05327 commented on GitHub (Jul 27, 2023):

The design is the same as GH, I think it's not a bug.

GH doesn't have private org, where does the same design come from?

@yp05327 commented on GitHub (Jul 27, 2023): > The design is the same as GH, I think it's not a bug. GH doesn't have private org, where does `the same design` come from?

GiteaMirror commented

2025-11-02 09:03:36 -06:00

@lunny commented on GitHub (Jul 28, 2023):

The design is the same as GH, I think it's not a bug.

GH doesn't have private org, where does the same design come from?

I mean for public org.

@lunny commented on GitHub (Jul 28, 2023): > > The design is the same as GH, I think it's not a bug. > > GH doesn't have private org, where does `the same design` come from? I mean for public org.

GiteaMirror commented

2025-11-02 09:03:36 -06:00

@GiteaBot commented on GitHub (Dec 20, 2023):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Dec 20, 2023): We close issues that need feedback from the author if there were no new comments for a month. :tea:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10298