move "cvs access" tab into project, make it generic, and add issue maintainers

based on my experience with the form_alter() approach to allowing other certain people to be able to assign issues to each other (see http://drupal.org/node/4354 and http://drupal.org/node/67251), along with my discussions with halkeye about his http://drupal.org/project/subversion module (see http://groups.drupal.org/node/790), i'm thinking i implemented the "cvs access" tab all wrong [1]. ;) here's my new proposal:

1. code in the project module should optionally produce a "file access" tab (there'd be a checkbox on the project edit form to enable this). the tab would generate/remove records in a {project_file_maintainers} table. this table would serve the purpose of the existing {cvs_project_maintainers} table.
2. the cvs.module (to the extent it cares at all) should just use {project_file_maintainers}. in fact, it's really the xcvs-* scripts that are going to care, but that'll be a relatively easy change.
3. there would be a 2nd tab, with the same UI as the "file access" tab, called "issue maintainers". this tab would automatically include all the users with file access as "locked" rows. everyone listed in either table would be in the "assignees" list for each other.

so, you'd end up with 3 tiers: project owner (full powers), file maintainer (revision control access, whatever that means for your site, etc), issue maintainers (additional rights in the issue queue).

for extra credit, i'd like to see all projects where i'm an issue maintainer in my http://drupal.org/project/user listing. ;)

in fact, i think this "issue maintainer" notion (on a per-project basis) is the right way to handle the per-status access control we're currently doing site-wide via permissions. i think it makes far more sense to let project maintainers define that stuff if they care, and select what status values the various tiers (plus the default "authenticated users" and "anonymous users" roles) are allowed to use. but, that's another story. ;)

i could maybe imagine still wanting a hook for who can be assigned tickets, but i kind of doubt it.

the key thing is making these two tables not specific to CVS, etc, but generic uid/nid tables that different modules can interpret however they please. you might argue that it'd be better to just use a single table and have a other field(s) which would be set to some well-defined int constant(s). i could make arguments for either approach, i think both have pros and cons. either way simplifies some code and complicates other code, and since we'd never store duplicate records, 2 tables wouldn't take up more space. i suppose there'd be fewer total DB queries with 1 table, which is probably the winning argument. in that case, we just call it {project_maintainers} and add either 1 additional int field with different constants, or separate bool fields (if DBs had bools, of course) for each kind of access a given user should be granted. separate fields is more flexible, but i'm not sure if we need that flexibility yet.

-derek

[1] dries, killes, and chx will notice that this new approach is pretty similar what i proposed to do originally when i first started the contrib cvs access stuff, but they rightfully steered me towards a more simple approach that would be easier to get going immediately. ;) oh well, here we are a few months later, and i think we're already starting to outgrow that solution. such is life...