Taxonomy or role-based platform access control for site creation

So here is a quick use case to get an Idea of why i think this is useful in some cases:

Say you have a group of Users/Clients running a Drupal 6 platform. You want to make sure that they have only access to create, migrate, and clone sits in this Drupal 6 platform area. Well currently you could go per User/Client and give them permissions to do this. Now here is where the problem would come in, lets say you have around 100 -200 users/clients and you are now releasing a security update say from D6.16 to D6.17, you would have to go to each user/client and give them permission to use the new platform. This is tedious and not realistic way to run a hosting service.

Instead you should have a way to group users and give these user/client groups permissions, keeping granularity for special cases. So something like the existing permissions system in drupal, applied to the platforms available in your aegir host. this way when you add a new Drupal 6.17 platform you can add permissions to use it to the groups you wish, then presto your users/clients in this group can upgrade their site to the new platform when needed. This sort of automation is needed for setups where you have a lot of clients or where you have low-end clients whom you dont or cant profitably spend a lot of time on upgrading/giving permissions too.

a suggestion was made by vertice to try Taxonomy Access to accomplish, before using custom code or a new module I will try and report back here.

It looks like adding access control based on taxonomy (http://drupal.org/project/taxonomy_access) is likely the best solution to accomplish this.

From a recent IRC conversation:

12:03:44 PM) chrismcintosh: i think another thing we will need to add to aegir system is setting up platform access based on Role, instead of just per user
(12:03:55 PM) chrismcintosh: i think thats probably the first thing im going to tackle
(12:04:23 PM) chrismcintosh: ergonlogic: what i could use help with though is converting my code into a good patch,  For some reason i have yet to figure out how to get that done right
(12:04:41 PM) ergonlogic: chrismcintosh: it's not per user now, but per client
(12:04:56 PM) chrismcintosh: ergonlogic: right, thats what i meant
(12:05:16 PM) ergonlogic: clients don't have roles though, users do
(12:06:16 PM) vertice: it should be per client
(12:06:36 PM) vertice: imo
(12:06:55 PM) vertice: there's an extra thing that needs to be in the client / user relationship
(12:07:03 PM) vertice: ie: what kind of user is this for the client
(12:07:06 PM) vertice: there's a ticket for that
(12:07:17 PM) vertice: it needs to be more flexible than just roles
(12:07:29 PM) ergonlogic: vertice: unless you intend to have lots of small clients as do chrismcintosh and me
(12:07:35 PM) chrismcintosh: right, granularity down to user is good
(12:07:40 PM) vertice: because a user can have multiple clients, but have different relatiomnships to clients
(12:07:54 PM) ergonlogic: chrismcintosh: http://drupal.org/node/899764
(12:08:00 PM) chrismcintosh: vertice: okay here is a use case though
(12:08:25 PM) ergonlogic: chrismcintosh: may be worth clarifying
(12:08:29 PM) chrismcintosh: say you have a group of users, that you want to give access to a Drupal 6 platform, but not drupal 7 for some reason
(12:08:38 PM) vertice: the role system isn
(12:08:41 PM) vertice: t powerful enough for this
(12:08:50 PM) vertice: it's orthogonal to client access
(12:09:08 PM) vertice: you could use taxonomy access
(12:09:11 PM) chrismcintosh: you could individually set each client to access for that, but say later on you add an upgrade say from 6.17 to 6.18
(12:09:12 PM) vertice: for instance
(12:09:15 PM) vertice: and tag the platforms
(12:09:23 PM) vertice: and have a node access mechanism based on user roles
(12:09:37 PM) chrismcintosh: vertice: would that work?
(12:09:44 PM) vertice: possibly
(12:09:52 PM) vertice: if you had the right access module for the taxo
(12:09:56 PM) vertice: is there a taxo_role module
(12:09:58 PM) chrismcintosh: i tried acl for some access control and it didnt filter anything on the create site form
(12:09:59 PM) mode (+o anarcat) by ChanServ
(12:10:00 PM) vertice: because in the end they are just roles
(12:10:14 PM) vertice: we pass it through db_rewrite_sql
(12:10:18 PM) vertice: i think
(12:10:26 PM) vertice: and how recently did you try it
(12:10:29 PM) vertice: that code is all new
(12:10:58 PM) vertice: i basically dont think something like that needs to be baked into code
(12:11:04 PM) vertice: especially not the core code
(12:11:13 PM) chrismcintosh: i am running on head that i installed last week i think
(12:11:25 PM) vertice: you should also check the hosting_available_options
(12:11:28 PM) vertice: it has an alter hook
(12:11:33 PM) vertice: that you can use to remove platforms
(12:11:35 PM) vertice: from the list
(12:11:45 PM) vertice: based on whatever
(12:14:45 PM) ergonlogic: vertice: Taxonomy Access Control (http://drupal.org/project/taxonomy_access) looks like the module you mentioned
(12:15:51 PM) vertice: yah
(12:15:52 PM) vertice: looks right
(12:16:02 PM) vertice: the platform nodes are just that. nodes
(12:16:10 PM) vertice: you should be able to add a taxo to them and tag them
(12:16:16 PM) vertice: and then use this to filter them per role

Okay so a couple of issues going on here. I tried TAC and it did not work, switched to Node Access module, and it did not work at filtering either. Turns out that there is not any real tracking going on for the platforms as far as permissions goes. So what i did first was change:

in site/hosting_site.form.inc change this line:
if ($platform->platform_status != HOSTING_PLATFORM_LOCKED ) {
to this
if ($platform->platform_status != HOSTING_PLATFORM_LOCKED && node_access('view', $platform)) {

There is more to come, but i got a quick meeting, and will follow up a bit more after

okay so the above solution does not work fully, the reason being is if you give a user access to view a node, they could then go to the Platform's actual node. Per vertice we need a List permision so that we can list the node, but not give access to it.

So what i did was change the hosting_platform.module line 79 to this:
$perms = array('create platform', 'view platform', 'list all platforms', 'edit platform', 'delete platform', 'view locked platforms');
$obj = _hosting_get_platforms();
foreach($obj as $platform){
if($platform !== 'hostmaster'){
$perms[] = 'list '.$platform.' platform';
}
}
return $perms;

then in hosting_site.form.inc we do this on line 126:
if ($platform->platform_status != HOSTING_PLATFORM_LOCKED && user_access('list all platforms', $user) || user_access('list '.$title.' platform', $user) ) {

this gives the ability to filter based on a new view permission that is being set in the hosting_platform.module

subbing

A better title. I think this should focus on filtering and frontend access control, and this would give users creation rights on the sites, but not necessarily rights to the whole platform itself, see #1345120: platform access control settings should allow full access to the platform for resolving that ambiguity.

In a way, maybe this is outside the scope of aegir - maybe a thirdparty module or just some fiddling with access control should do this. Platforms should be node_access-ready, but beyond that, I am not sure it's that important we deal with this further, within the scope of Aegir, because uc_hosting or other modules will have different ways of doing this (a custom table for uc_hosting, taxonomy for development teams, etc).

So in a way, I see this issue as a duplicate of #725952: implement node-level access permissions for platforms - am I missing something here?

probably. i have moved on from needing this my self. with having a front end store for aegir, most of my users do not have any way to know what the platforms are. We probably could close this issue unless someone else still needs it

This could be handled in contrib, and no activity in 3+ years, so closing here.