It might also be useful to have a ticket access level too, so users can be granted permissions to manage tickets, but not have direct commit access to the main repo.

Related: issue #829

#46 seems categorically related as well, enabling ie 'production' and 'development' team access levels.

Branch ACLs is a different issue from the UI ACLs as one is related to gitolite the other to the web app :)

Looking at #829 and this issue itself, there should be 4 access levels:

1. None
2. Commit Access
3. Ticket Access
4. Admin

Here is what i understand of these accesses:

1. None: nothing special, just normal stuff
2. Commit Access: Push directly to the upstream repo, Access to merge a PR
3. Ticket Access: Access to change metadata of the issues in the repo, closing the issue included
4. Admin: settings access + everything else.

@pingou @ryanlerch How do you want to add new users to the new access levels? Just like we add owners to a repo?

@pingou thoughts?

This sounds quite reasonable.

Regarding users management, I think we could simply do that in the settings with having a drop-down list next to the username allowing to pick the access level.

One question: does commit grant you ticket access or vice-versa or are they entirely separated?
(So one would get commit but w/o being able to edit ticket).

I am thinking toward doing some more along the lines of:

1. No access
2. Ticket access: Access to change metadata of the issues in the repo, closing the issue included
3. Commit access: ticket access + Push directly to the upstream repo, Access to merge a PR
4. Admin access: commit access + access to the project's settings

How does that sound?

yeah, i guess this one is better. A guy who can commit on master directly should be able to close the tickets .

:thumbsup:

Also, when you assign a group to a project what level of access do all the members of the group get?

And what happens if a group member assigned to that project is also assigned to the project too?

When the group is assigned to a project, the group members are admins of the project. And in the second case, we can have a priority system: admin being the highest and none being the lowest. The higher one is chosen.

I think we could have groups behave just like users with an ACL level, so group foo would be for editors while bar would be for contributors and foobar for admins (or so).

Then when checking the user's access, we simply need to figure out if by the groups the user has higher access

yup, i had the same thought.

Fixed in #1796 , #1824 and #1825