More fine-grained permissions for issues

[KazzmanK]

Feature Description

Lets have a User as a member of team, that has Read access to Issues in particular repository. User have an ability to write new issues! Looks like a bug (1.20). At the same time user is not able to set labels, milestones, close issue etc

If user is appointed as Assignee, maybe it is Okay to let him set labels, milestones, transfer assignees?

What I try to achieve - disallow user to Close Issues, but allow User set Done label to signal others to check the results.

Screenshots

No response

[lafriks]

This is intended behavior. Read rights allows to create new issues and comment them but only with write rights you can edit issue properties (labels/milestones etc). Usually such things can be done by using some kind of bot to allow certain actions

[Red3Tango]

With the new "Everyone Write" option for public wiki access added in 1.24.0 #34051. Could this possibly be expanded to Issues and Projects? Many new users complain to me that they don't understand when they set "read" permissions, it gives people "write" permissions.

Currently in 1.24.0 if you set Public Access to "Anonymous Read" this will act like "Everyone Read" if you are logged in. This seems like it is more of a elevation of permissions, and not expected behavior.

My proposal would be to change:

• Not Set: (no change)
• Anonymous Read: all users can access the unit with read permissions. (logged-in can view but not create)
• Everyone Read: all logged-in users can access the unit with read permission. (logged-in user can create/comment)
• Everyone Write: all logged-in users have write permission to the unit. (logged-in users can edit properties)

This would allow admins to set either "Everyone Read" or "Everyone Write" and this would be the "intended behavior" to follow what GitHub uses. Changing "Anonymous Read" to satisfy the OP and #27773, by allowing only logged-in users to view (read) but not create (write)