Finer permission controls for users to prevent spam

[pgaskin]

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.

[pgaskin]

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

[strk]

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 ?

[pgaskin]

@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

[strk]

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;

[pgaskin]

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.

[strk]

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 ?

[pgaskin]

Should this permission be per-repository then ?

Yes and also a global setting per user

[pgaskin]

@strk Should I add allowed to edit wikis?

[lunny]

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

[strk]

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

[strk]

See also #1377 for setting limits

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.