{"id":27255,"date":"2017-01-27T07:08:33","date_gmt":"2017-01-27T15:08:33","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/?p=27255"},"modified":"2019-02-14T15:55:52","modified_gmt":"2019-02-14T23:55:52","slug":"splitting-up-git-administer-permissions","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/splitting-up-git-administer-permissions\/","title":{"rendered":"Splitting up Git administer permissions"},"content":{"rendered":"

Like everything in VSTS and TFS, Git repos are protected by a set of permissions<\/a>. For instance, you must have Read<\/em> for a repo\u00a0to clone or view its contents. Likewise, you must have Contribute<\/em> to push changes. Until recently,\u00a0you needed one permission to create, delete, or rename a repo, edit branch policies, or change other people’s permissions: Administer<\/em>.<\/p>\n

We heard from several customers that\u00a0Administer<\/em>\u00a0covered too many scenarios. For instance, at one customer, anyone can create new repos and rename any repo they created. Due to compliance regulations, no one can\u00a0delete a repo they created (only a select group of people have that capability). At another customer, for company policy reasons, separate individuals control branch policies (the repo owner), adding & removing other people’s permissions (project administrators), and deleting repos (like the previous customer, restricted to only a handful of people).<\/p>\n

With\u00a0Administer<\/em> covering all of these capabilities in one permission, both customers were unable to delegate some authority without delegating all authority. In practice, this meant that only a small set of people were responsible for all repo creation and management, creating a bottleneck for engineers every time they wanted a new repo.<\/p>\n

You’ve probably guessed what I’m going to say next: we’ve split the Administer<\/em> permission into 6 new permissions. Those new permissions are:<\/p>\n

    \n
  1. Create repository<\/li>\n
  2. Delete repository<\/li>\n
  3. Rename repository<\/li>\n
  4. Edit policies<\/li>\n
  5. Manage permissions<\/li>\n
  6. Remove others’ locks<\/li>\n<\/ol>\n

    We automatically migrate permissions on upgrade (meaning that if you previously had Administer<\/em> on a a repo or at the project level, you now have these 6 new permissions on that repo or project). When you create a new repo, we automatically grant Delete<\/em>, Rename<\/em>, Edit policies<\/em>, Manage permissions<\/em>\u00a0and Remove others’ locks<\/em> on that repo, equivalent to the old behavior of granting\u00a0Administer<\/em>.<\/p>\n

    We also took this opportunity to clean up the names of a few existing permissions. Several of them were awkwardly phrased. “Force push” is a well-understood Git concept, so we promoted it to the front of its corresponding permission name. Mapping from old name to new, the renamed permissions are:<\/p>\n