Gitlab: team member project access levels

2013: The project_security_spec.rb test each profile capabilities, which are listed in ability.rb:

(2017 GitLab 10.x: this would be more likely in app/policies/project_policy.rb)

See also, as noted in jdhao’s answer: “Project members permissions”

Those rules are quite explicit:

def public_project_rules
  [
    :download_code,
    :fork_project,
    :read_project,
    :read_wiki,
    :read_issue,
    :read_milestone,
    :read_project_snippet,
    :read_team_member,
    :read_merge_request,
    :read_note,
    :write_issue,
    :write_note
  ]
end

def project_guest_rules
  [
    :read_project,
    :read_wiki,
    :read_issue,
    :read_milestone,
    :read_project_snippet,
    :read_team_member,
    :read_merge_request,
    :read_note,
    :write_project,
    :write_issue,
    :write_note
  ]
end

def project_report_rules
  project_guest_rules + [
    :download_code,
    :fork_project,
    :write_project_snippet
  ]
end

def project_dev_rules
  project_report_rules + [
    :write_merge_request,
    :write_wiki,
    :push_code
  ]
end

That means:

• a reporter is a guest who can also:
  • download code,
  • fork a project,
  • write project snippet
• a developer is a reporter who can also:
  • write merge request,
  • write wiki pages,
  • push code

Note: with GitLab 15.0 (May 2022):

Users with the Reporter role can manage iterations and milestones

We’ve changed the permissions necessary to create, edit, and delete milestones and iterations from the Developer to Reporter role.

This change better reflects the typical day-to-day Reporter responsibilities of managing and tracking planning timeboxes.

See Documentation and Issue.