Permission granularity for domain-specific administration

So... I don't know if I'm on the right track here or not, but I played with the code a bit to see if I could implement a more general "Administer own domains" permission, while keeping the functionality otherwise identical. I've got a prototype more or less working, but there is at least one bug, and it currently only works for the theme settings. Bear in mind that I have no real coding experience, so please forgive my fumbling attempts here.

I took a brute force approach, creating a new 'administer own domains' permission, stuck a new item ('My Domains') in hook_menu() calling a new function my_domain_view(). This last is a wholesale copy of domain_view() with the SQL hardcoded, as I haven't yet figured out how "module_invoke_all('domainview', 'join')" works, nor how to add my own JOIN and WHERE to filter by $user->uid.

Following a similar approach, I used the 'administer own domains' permission in the domain_theme.module hook_menu(), adding page callbacks to my_domains_theme_page, my_domains_theme_reset and my_domains_theme_settings. I added my_domains_lookup() to generate a $my_domains variable for these new functions.

So, while this successfully limits access to domain theme settings, it appears to limit it to only the first domain found in the domain_editor table, which indicates to me that the bug is in the SQL of the my_domains_lookup() function.

I can't help but think that there's a more elegant way of doing this. I'm also pretty sure that I've violated some Drupal coding and/or naming conventions, patched against a version other than -dev, and probably a couple more mortal sins.

Ah, I see. I've checked out CVS HEAD.

So, if a proper 'administer own domains' permission were to be implemented, what changes would be required from an architectural and UI standpoint?

What if this permission were only added to the admin/build/domain/view menu item? Could changes then be limited to hook_domainlinks(), and hook_domainview()? Perhaps using domain_get_user_domains() to set $domain rather than domain_domains()?

What I'm trying to get at is if the 'administer own domains' permission was limited to only domain-specific functionality, couldn't this be achieved by only ever returning a list of the user's assigned domains (minus the default domain) to all other functions?

Since there's no 7.x version currently, set to 6.x-2.x-dev.

domain_list()? Do you mean domain_view()?

If that is the case, then this patch should do it.

Is this better? Sorry for the newbie errors. I appreciate your guidance.

How important is '-p' option for diff?

OK, so this patch adds filtering the list of domains to just assigned domains should the user only have the 'administer own domains' permission. I don't know that this is the proper approach, nor that it is secure, but it appears to work.

I believe the use-case for 'administer own domains' should probably exclude domain 0. Similarly, while 'edit' makes sense, permission to 'delete' should probably remain with 'administer domains'. I'll work on these next.

This patch implements the domain_view() UI tweaks mentioned in my previous comment, as well as elaborating the access callback to handle menu arguments passed from domain sub-modules. As far as I can tell, this patch implements all the features discussed above. It requires patching domain sub-modules to have menu items use the domain_admin_access() callback and pass access arguments, if any.

However, all of this only appears to work from the primary domain, and 'access denied' errors are presented whenever I try to access these functions from a subdomain. While this certainly makes sense for the 'administer domains' permission, it seems to me that 'administer own domains' should allow access from the appropriate subdomains.

It looks like you were right, with regards to the domain sub-modules. But for domain_form() (/admin/build/domain/edit/[domain-id]), I had to add the ignore_domain_status_check argument.

This patch also updates the access callbacks in domain_conf.module. I can confirm that this works with domain_theme.module too, but since that module seems to have split off in HEAD, it isn't included in this patch.

AFAIK, this patch works as advertized. Should I go ahead and patch the rest of the sub-modules' access callbacks? I'm not familiar enough with them to know whether an 'administer own domains' makes sense in those contexts.

Like so, for domain_conf?

Okay, if I understand correctly, the "administer" permissions should be necessary, but not sufficient for the configuration of each of the sub-modules.

So, I've added or modified the permissions in domain_alias, domain_conf and domain_content. The rest (domain_nav, domain_source and domain_strict) don't appear to have any configuration options, and don't add any items to domain_view(), and so haven't been changed.

Try the attached module instead. It implements the functionality discussed, though there remains an issue with the domain admin page at admin/build/domain.

Basically, additional domain-related modules' links are created, whether the user has the additional permissions or not. Clicking one of these will result in an 'Access Denied' error. This suits my use-case, as I'm not currently using this page. From what I can tell, I'd have to create a custom version of the function that creates this page that checks whether the current user as access to the link, and removes it if not.

If there's interest and agentrickard doesn't have an objection, I could publish this properly as a module, though I think a better name would be in order.

I figured as much from http://drupal.org/node/607824#comment-2675540. I'm happy to maintain it myself, as it's fairly basic.

Any suggestions for a better name would be welcome.

@agentrickard: Thanks, I'll give it some thought.

Now that I'll be releasing my little module, my perfectionist streak kicks in :/. So, I should probably only show the permissions if the appropriate sub-module is enabled.

@brt: Have you looked at http://drupal.org/project/domain_user_edit?

FYI: I recently published a module based on the foregoing discussion: Domain Admin. Feel free to make any feature or support requests there.

Also, the folks behind Domain Administration Helper have contacted me to discuss merging our respective modules to "create a really great admin delegation suite".

@agentrickard: Thank you for your help and patience as I cut my teeth on this issue. Should you decide to include any of this functionality in Domain Access, I'd be happy to roll some patches for you.

@brt: Thanks for the motivation to actually publish this.