Finer permission controls for users to prevent spam #484

New Issue

GiteaMirror · 2025-11-02T03:25:05-06:00

GiteaMirror commented

2025-11-02 03:25:05 -06:00

Originally created by @pgaskin on GitHub (Mar 12, 2017).

Permissions to add:

Allowed to create issues
Allowed to create pull requests
Visible on user list
Allowed to comment on issues
Allowed to upload files

@lunny @bkcsoft @strk @tboerger feel free to edit this post.

Originally created by @pgaskin on GitHub (Mar 12, 2017). ### Permissions to add: - [ ] Allowed to create issues - [ ] Allowed to create pull requests - [ ] Visible on user list - [ ] Allowed to comment on issues - [ ] Allowed to upload files @lunny @bkcsoft @strk @tboerger feel free to edit this post.

GiteaMirror added the issue/confirmed type/feature labels 2025-11-02 03:25:05 -06:00

GiteaMirror commented

2025-11-02 03:25:06 -06:00

@pgaskin commented on GitHub (Mar 12, 2017):

Original post for future reference:

Each user should have permission settings as in:

Allowed to create issues
Allowed to create pull requests
Visible on user list
Allowed to comment on issues
Allowed to upload files

@pgaskin commented on GitHub (Mar 12, 2017): ### Original post for future reference: Each user should have permission settings as in: - Allowed to create issues - Allowed to create pull requests - Visible on user list - Allowed to comment on issues - Allowed to upload files

GiteaMirror commented

2025-11-02 03:25:06 -06:00

@strk commented on GitHub (Mar 12, 2017):

How's "create pull-request" different from "create issues" ?
Should "Visible on user list" be a user choice rather than an admin choice ?

How about allowing creation of forks but not of repositories not being fork of other repositories ? Like with delta not bigger than a give amount of bytes and number of commits ?

@strk commented on GitHub (Mar 12, 2017): How's "create pull-request" different from "create issues" ? Should "Visible on user list" be a user choice rather than an admin choice ? How about allowing creation of forks but not of repositories not being fork of other repositories ? Like with delta not bigger than a give amount of bytes and number of commits ?

GiteaMirror commented

2025-11-02 03:25:06 -06:00

@pgaskin commented on GitHub (Mar 12, 2017):

@strk

How's "create pull-request" different from "create issues" ?

There are different tabs for pull requests and issues

Should "Visible on user list" be a user choice rather than an admin choice ?

It should be both because a user may want to be private, and an admin might want to hide a bot or a bad user

How about allowing creation of forks but not of repositories not being fork of other repositories ? Like with delta not bigger than a give amount of bytes and number of commits ?

Yes, that sounds good

@pgaskin commented on GitHub (Mar 12, 2017): @strk > How's "create pull-request" different from "create issues" ? There are different tabs for pull requests and issues > Should "Visible on user list" be a user choice rather than an admin choice ? It should be both because a user may want to be private, and an admin might want to hide a bot or a bad user > How about allowing creation of forks but not of repositories not being fork of other repositories ? Like with delta not bigger than a give amount of bytes and number of commits ? Yes, that sounds good

GiteaMirror commented

2025-11-02 03:25:06 -06:00

@strk commented on GitHub (Mar 12, 2017):

On Sun, Mar 12, 2017 at 08:24:46AM -0700, Patrick G wrote:

There are different tabs for pull requests and issues

Ok but why would you want someone to be able to file PRs but
not issues ? Or vice-versa. I'm not against it, just could be
more than needed :)

Should "Visible on user list" be a user choice rather than an admin choice ?

It should be both because a user may want to be private, and an admin might want to hide a bot or a bad user

Good point.

Yes, that sounds good

Now this is where issues become suboptimal.
You could either edit the original submission (with the result
of the comment becomes weird) or move the plan into a wiki
page maybe ? Or, we have a "proposals" repository which was created
specifically for this, although it's not clearly documented how proposals
should look like. Maybe could be documents like RFCs inside the
"proposal" repository.

What do others think about this ?
\cc @tboerger, @lunny, @bkcsoft

--strk;

@strk commented on GitHub (Mar 12, 2017): On Sun, Mar 12, 2017 at 08:24:46AM -0700, Patrick G wrote: > There are different tabs for pull requests and issues Ok but why would you want someone to be able to file PRs but not issues ? Or vice-versa. I'm not against it, just could be more than needed :) > > Should "Visible on user list" be a user choice rather than an admin choice ? > > It should be both because a user may want to be private, and an admin might want to hide a bot or a bad user Good point. > Yes, that sounds good Now this is where issues become suboptimal. You could either edit the original submission (with the result of the comment becomes weird) or move the plan into a wiki page maybe ? Or, we have a "proposals" repository which was created specifically for this, although it's not clearly documented how proposals should look like. Maybe could be documents like RFCs inside the "proposal" repository. What do others think about this ? \cc @tboerger, @lunny, @bkcsoft --strk;

GiteaMirror commented

2025-11-02 03:25:07 -06:00

@pgaskin commented on GitHub (Mar 12, 2017):

Ok but why would you want someone to be able to file PRs but not issues ? Or vice-versa. I'm not against it, just could be more than needed :)

For example in a company, if you do not want some employees fixing the code

Now this is where issues become suboptimal. You could either edit the original submission (with the result of the comment becomes weird) or move the plan into a wiki page maybe ? Or, we have a "proposals" repository which was created specifically for this, although it's not clearly documented how proposals should look like. Maybe could be documents like RFCs inside the "proposal" repository.

I will edit my second comment and that is where the final list will go. Feel free to edit it.

@pgaskin commented on GitHub (Mar 12, 2017): > Ok but why would you want someone to be able to file PRs but not issues ? Or vice-versa. I'm not against it, just could be more than needed :) For example in a company, if you do not want some employees fixing the code > Now this is where issues become suboptimal. You could either edit the original submission (with the result of the comment becomes weird) or move the plan into a wiki page maybe ? Or, we have a "proposals" repository which was created specifically for this, although it's not clearly documented how proposals should look like. Maybe could be documents like RFCs inside the "proposal" repository. I will edit my second comment and that is where the final list will go. Feel free to edit it.

GiteaMirror commented

2025-11-02 03:25:07 -06:00

@strk commented on GitHub (Mar 12, 2017):

On Sun, Mar 12, 2017 at 09:08:56AM -0700, Patrick G wrote:

Ok but why would you want someone to be able to file PRs but not issues ? Or vice-versa. I'm not against it, just could be more than needed :)

For example in a company, if you do not want some employees fixing the code

Should this permission be per-repository then ?

@strk commented on GitHub (Mar 12, 2017): On Sun, Mar 12, 2017 at 09:08:56AM -0700, Patrick G wrote: > > Ok but why would you want someone to be able to file PRs but not issues ? Or vice-versa. I'm not against it, just could be more than needed :) > > For example in a company, if you do not want some employees fixing the code Should this permission be per-repository then ?

GiteaMirror commented

2025-11-02 03:25:07 -06:00

@pgaskin commented on GitHub (Mar 12, 2017):

Should this permission be per-repository then ?

Yes and also a global setting per user

@pgaskin commented on GitHub (Mar 12, 2017): > Should this permission be per-repository then ? Yes and also a global setting per user

GiteaMirror commented

2025-11-02 03:25:07 -06:00

@pgaskin commented on GitHub (Mar 12, 2017):

@strk Should I add allowed to edit wikis?

@pgaskin commented on GitHub (Mar 12, 2017): @strk Should I add allowed to edit wikis?

GiteaMirror commented

2025-11-02 03:25:07 -06:00

@lunny commented on GitHub (Mar 13, 2017):

I'm working on first step. Different team could display different tabs. See #947

@lunny commented on GitHub (Mar 13, 2017): I'm working on first step. Different team could display different tabs. See #947

GiteaMirror commented

2025-11-02 03:25:07 -06:00

@strk commented on GitHub (Mar 13, 2017):

Yes, edit wiki seems important to me. I hate the current limitation
of wiki editors being necessarely the same as repo editors...

@strk commented on GitHub (Mar 13, 2017): Yes, edit wiki seems important to me. I hate the current limitation of wiki editors being necessarely the same as repo editors...

GiteaMirror commented

2025-11-02 03:25:08 -06:00

@strk commented on GitHub (Mar 23, 2017):