Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 55.4k
    • Issues 55.4k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.6k
    • Merge requests 1.6k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #11877
Closed
Open
Issue created May 31, 2019 by Mark Chao@lulalala🔴Maintainer

Public project-level approval rules API

  • Make new API public and documented
  • Make some API deprecated

Description

The new approval rule system comes with some new API endpoints. They are private API for now. However we have to make them public (and fixed) in order to deprecate the old endpoints.

Rename endpoints for consistency

Currently we have:

  • GET /projects/:id/merge_requests/:merge_request_iid/approvals (public, expose most of ApprovalState infos)
  • GET /projects/:id/merge_requests/:merge_request_iid/approval_settings (private, provides all rule infos)
  • GET /projects/:id/approval_settings (private, provides all rule infos)

I feel user might be confused between the two. Would renaming approval_settings to approval_rules makes sense for both MR and project level endpoints?

Edited Aug 14, 2019 by Mark Chao
Assignee
Assign to
Time tracking