Extend project maintainer UI for manipulating git project ACLs

I was thinking about this the other day, and I think it'd be reasonable safe to push per-branch permissions to phase 3. We don't have this now, and we seems to get along okay (I don't know of any requests to add it, or any projects needing it), and since we'll already be metering access by repo, that will map well to the per-directory solution that we have now in CVS.

Branch-level grants is definitely phase 3, except if it's easier to do that directly in phase 2.

well I don't think core should hold us up there, core maintainers are trustworthy enough to not behave properly.
So this issue probably needs to be splitted, one for per-branch permissions (phase 3) and one for the general UI+gitolite backend for phase 2.

Yes, and this doesn't belong as a d.o infra issue. The UI for this is going to be provided by versioncontrol_project.module and friends. In fact, I bet this issue is a duplicate, but I don't have time to search right now.

I'm actually tempted to call this duplicate with #69556: move "cvs access" tab into project, make it generic. I'm wondering if this should be versioncontrol_project's problem at all, or if we want a more generic solution in project itself.

adding redesign tags

This is blocked on #69556: move "cvs access" tab into project, make it generic. Once that issue is done and deployed, this issue can become active again for injecting a "Maintain version control" checkbox (or whatever) on the /node/N/maintainers tab on project nodes and then save those values into the appropriate vcapi tables.

I'll be working on this for sprint #2

Not at all. There's a "Write to CVS" checkbox from cvs.module thanks to #880818: Remove CVS access tab in favor of the project maintainers form. We have no such checkbox provided by vc_project that tells vcapi to give user N access to write to the VCS for project X. It's easy, but not done.

This is for Git, not d.o redesign.

Spoke with sdboyer about this in #drupal-vcs the other day and I'm going to try to sum up my understanding as closely as possible.

Since each module that hooks into project_maintainer permissions is responsible for storing it's data and permissions itself, the question was where the permissions that are exposed via the maintainers tab would be stored. Would it be in a table owned by versioncontrol_project (associated with the project ID), or as part of VC API (associated with the repo ID)? The conclusion seems to be that although VC API has this functionality know, it's going to be killed, and that versioncontrol_project should store this data in it's own tables, and not worry about interfacing ACLs with VC API until VC API supported per branch permissions.

We need to talk to Sam, then, since I think it'd be a terrible mistake for VCAPI to only support ACLs via vc_project. That means each backend would have to know about vc_project to be able to handle ACLs at all. ACLs seemed to be one of the few features that all VCS's want to support that could fairly easily be abstracted by VCAPI, instead of having tons of low-level logic without any layer of indirection. This sounds like a giant regression in VCAPI to me. Before we work on this, we need to discuss and clarify why we're taking such a big step backwards...

Details about what is going to happen with authentication on vcs api: #223891: API change: make authentication management pluggable (we are now in the process of re-factor accounts inside the vcs api).

BTW commit_restrictions module is not really touched long time ago, but we probably want to discuss about it after the re-factor is done. I do not see the removing of that module IIRC.

Tagging for Git Sprint 7.

Assigning this to myself since I'm getting started on it.

Upping version.

This is a start to making project maintainer permissions work. This is just all or nothing access to each repo, and deleting a user doesn't work due to #1003946: VersioncontrolAuthHandlerMappedAccounts has no way to delete rows from auth table. This also requires #1003904: Queries in VersioncontrolAuthHandlerMappedAccounts::save not actually executed to be applied, or updating maintainer perms will fail.

The two issues mentioned in #22 are resolved, and this is 99% working, although it still needs the patch from #1003552: Pass the project to hook_project_permission_info() to be applied to project to get the proper context to show the correct perms, even though we could parse this from menu_get_object.

From a Project* perspective, this mostly looks fine to me, with the following minor nitpick:

A) This chunk:

  if ($repo && $repo->plugins['auth_handler'] == $plugin) {
    return TRUE;
  }
  return FALSE;

could be simplified to:

  return $repo && $repo->plugins['auth_handler'] == $plugin;

Besides that, this seems fine. Ideally, we'd get one of the VCAPI maintainers to also review this to make sure they're also happy. ;) Otherwise, I'd just RTBC this myself right now.

Well, I guess needs work for 24.A...

Fixed the issue from #24.

I'm still not thrilled with the flexibility and pluggablity of this approach, there are a number of conditions where it would start to break down with radically different repo structures (such as multiple projects per repo), but this should work okay for now provided that the twisted ssh/git server likes the data that VC API exposes from the auth plugins.

Found some bugs in this when saving an existing, or new node. I just need another place to check the existence of a repo for a given project since it may not be loaded onto a node that is being saved, as I'm currently checking in hook_project_permission_info().

Swapped this around to use the helper function for loading a repo given a known project_id instead of counting on the repo being populated when saving the node.

Committed the patch from #29.