Issue VS code permissions #4376

New Issue

GiteaMirror · 2025-11-02T05:48:42-06:00

GiteaMirror commented

2025-11-02 05:48:42 -06:00

Originally created by @vincentdavis on GitHub (Nov 23, 2019).

I see some related issues related to permissions. I think having separate permissions for code and issues would be a good idea. Then maybe in the future allow per repo or team permissions that define both issue and code permissions.

My need: I need to allow some users to create, comment on issues but not be able to edit the code.
This is kinda akin to the permissions I have here making this issue and reading others.

I sent some sponsor money your way again. Keep up the great work!
Would be great if some part of this was in 1.11

Originally created by @vincentdavis on GitHub (Nov 23, 2019). I see some related issues related to permissions. I think having separate permissions for code and issues would be a good idea. Then maybe in the future allow per repo or team permissions that define both issue and code permissions. My need: I need to allow some users to create, comment on issues but not be able to edit the code. This is kinda akin to the permissions I have here making this issue and reading others. I sent some sponsor money your way again. Keep up the great work! Would be great if some part of this was in 1.11

GiteaMirror added the type/question issue/stale labels 2025-11-02 05:48:42 -06:00

GiteaMirror closed this issue

2025-11-02 05:48:42 -06:00

GiteaMirror commented

2025-11-02 05:48:43 -06:00

@guillep2k commented on GitHub (Nov 23, 2019):

You can have finely grained permissions if you move the repo to an organization and create teams for it. Each team individually can have access to code or issues etc. That's not available if the repo is under a normal user. You can create organizations using the [+] menu just at the left of your avatar.

@guillep2k commented on GitHub (Nov 23, 2019): You can have finely grained permissions if you move the repo to an organization and create teams for it. Each team individually can have access to code or issues etc. That's not available if the repo is under a normal user. You can create organizations using the `[+]` menu just at the left of your avatar.

GiteaMirror commented

2025-11-02 05:48:43 -06:00

@vincentdavis commented on GitHub (Nov 23, 2019):

@guillep2k
I have organizations defined but did not realize permissions where different there. I'll take a look.

@vincentdavis commented on GitHub (Nov 23, 2019): @guillep2k I have organizations defined but did not realize permissions where different there. I'll take a look.

GiteaMirror commented

2025-11-02 05:48:43 -06:00

@vincentdavis commented on GitHub (Nov 23, 2019):

@guillep2k I think that worked.
It is not clear what the result of choosing READ ACCESS and then NO CODE would be or for that matter wite and no code.

READ ACCESS. Members can view and clone team repositories. (yes)
CODE: Access source code, files, commits and branches. (no)

@vincentdavis commented on GitHub (Nov 23, 2019): @guillep2k I think that worked. It is not clear what the result of choosing READ ACCESS and then NO CODE would be or for that matter wite and no code. - READ ACCESS. Members can view and clone team repositories. (yes) - CODE: Access source code, files, commits and branches. (no)

GiteaMirror commented

2025-11-02 05:48:43 -06:00

@guillep2k commented on GitHub (Nov 23, 2019):

To be honest, I didn't check very well the effect of the permissions myself. As far as I understand, the following is true:

One user can belong to zero, one or more teams.
The highest permissions prevail.
A team can have read, write or admin permissions on different units. For example, a team can be admin for issues and nothing else. Then another team can be writer for code and nothing else. Finally, a user that belongs to both teams is writer for code and admin for issues.

There's a particular case that might be misleading and it's what actually is meant by read/write permissions on issues/pull requests:

None (*) means the issues/PRs can't be accessed at all.
Read means the user can view and comment on any issues/PRs, and can create, modify and delete their own issues/PRs.
Write means the user can view and comment on any issues/PRs, and can modify, delete other people's issues/PRs and comments.

(*) None happens when the user doesn't belong to any team that has at least read permissions.

@guillep2k commented on GitHub (Nov 23, 2019): To be honest, I didn't check very well the effect of the permissions myself. As far as I understand, the following is true: * One user can belong to zero, one or more teams. * The highest permissions prevail. * A team can have read, write or admin permissions on different _units_. For example, a team can be admin for issues and nothing else. Then another team can be writer for code and nothing else. Finally, a user that belongs to both teams is writer for code and admin for issues. There's a particular case that might be misleading and it's what actually is meant by read/write permissions on issues/pull requests: * **None** (*) means the issues/PRs can't be accessed at all. * **Read** means the user can view and comment on any issues/PRs, and *can create, modify and delete* their own issues/PRs. * **Write** means the user can view and comment on any issues/PRs, and can modify, delete other people's issues/PRs and comments. (*) _None_ happens when the user doesn't belong to any team that has at least read permissions.

GiteaMirror commented

2025-11-02 05:48:44 -06:00

@lunny commented on GitHub (Nov 23, 2019):

@vincentdavis You could create two teams. One team have write permission to issues unit, and another have write permission to code unit. I think that's done.

@lunny commented on GitHub (Nov 23, 2019): @vincentdavis You could create two teams. One team have write permission to issues unit, and another have write permission to code unit. I think that's done.

GiteaMirror commented

2025-11-02 05:48:44 -06:00

@mqgmaster commented on GitHub (Nov 26, 2019):

@lunny its working? At 1.8.2 the code tab is always visible and accessible for every repository of the team. The code option appears ignored. The @vincentdavis question is very good. Makes sense Read permission granted and Code access disable at same time?

@mqgmaster commented on GitHub (Nov 26, 2019): @lunny its working? At 1.8.2 the code tab is always visible and accessible for every repository of the team. The code option appears ignored. The @vincentdavis question is very good. Makes sense Read permission granted and Code access disable at same time?

GiteaMirror commented

2025-11-02 05:48:44 -06:00

@lunny commented on GitHub (Nov 26, 2019):

@mqgmaster Yes, I think it works from at least 1.8.0 .

@lunny commented on GitHub (Nov 26, 2019): @mqgmaster Yes, I think it works from at least 1.8.0 .

GiteaMirror commented

2025-11-02 05:48:44 -06:00

@stale[bot] commented on GitHub (Jan 25, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 25, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:48:45 -06:00

@stale[bot] commented on GitHub (Feb 8, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Feb 8, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:53:42 -06:00

[PR #4377] [MERGED] Replace src with raw to fix image paths #17353

Sign in to join this conversation.