I started testing the module yesterday and i love it. I was exactly looking for something like this. There are just some small things that i dont like:

First
As an admistrator with general access permissions i see all the content on all subsites even in the "Afiliated content" views.

Workarounds:
1. use a different browser and "normal user" to check and preview.
2. use coutom users "sub1" "sub2" "all" and devel module to switch between users with respectively limited permission

Both is very confusing and incnvenient.

Second
I want to use this module for a tourism site where every geografical region has its own site, with own Hotels, Places of interest, Background information. Its very easy to get what i want with subdomains and a view like hotels. Its almost magic how easy it is, without fiddling with arguments i get the hotels for each subdomain with just one view! Perfect!

BUT: The information that classifies my content to belong to a certain subdomain (section) is only in the access table. That means giving up many advantages.

Another approach (without this module) would be to assign my content with taxonomy. (Example Newspaper : http://drupal.org/information.dk) Then i could use Views to display my content. I could use a Filter refining and narrowing my search via taxonomy term and so on.

I feel a bit uneasy about giving away all these options and relying completely on Access control.

Easy Solution
A Module can own a Vocabulary. If the domain access module would synchronize the all access information with an (invisible) vocablulary, this information could be used in many ways. It would also be a step back towards "drupal core". Which is impotant i think and will increase the acceptance for this module.

Advantages:
1. The "Afiliated content" views could work even for "almighty" admins, using taxonomy to narrow the content views.
2. You gain access to all the opportunities taxonomy related modules give. Breadcrumbs, views integration, filtering, token, actions, workflows... Thats a whole universe of additional power.
3. The information to which category the content belongs (be it: regional, legal, logical) is searchable, it can be easier exported in case you need to create, lets say a pdf with all content of a section.
4. ...
...
100000. all the rest.

One implementation would be to just automatically tag the content with the subdomain(s), or provide a field in the subdomain settings page that holds a customizable term.

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I'm reading through this as I write it, and apologies if I sound defensive, but I'm not convinced that you have read the documentation or comprehend what this module tries to accomplish.

I appreciate that you're trying to help improve the module, but I just disagree with you on your major premise.

I wrote this module in part because I don't trust editors to use Taxonomy correctly to categorize content, so you're running into a use-case wall here. There are already plenty of modules that use Taxonomy as a category system. If our use-case required taxonomy-based access controls, this module would not exist.

That argument aside, these should probably be separate issues. Here are some thoughts.

1) That's the way node access works. I really can't do anything about it without going around the Drupal API. Node Access is a permissive OR system. So if you have the 'administer nodes' permission -- which is what I assume you mean by 'general access permissions' -- you can always see all nodes.

See section 5.5 of the README, which explains this in painstaking detail.

Don't believe me? Read the logic of node_access(). Ain't a thing I can do about that. In fact, I had to write the Domain Content module because Drupal's normal Content batch editing screen doesn't respect Node Access at all.

The behavior exists in cases where you run site(s) where some editors have limited permissions. Since user 1 (or an admin user with 'administer nodes') has all permissions, that user may have issues. But if you only have one adminstrator for your site, or if you always act as user 1, you probably don't need the editorial access anyway.

In theory, we could write explicit queries for these pages that don't use db_rewrite_sql() -- which is what invokes node access rules -- but if you do that, you might break other functionality introduced by the Drupal API.

You'll also notice, of course, that Node Access modules don't have any affect on users with 'administer nodes' when they _view_ the site. Also a big pain, but again, unavoidable. You have to preview the site in another browser as well.

So #1 is a "won't fix" -- although it might be acceptable to me if you found a way to let users with 'administer nodes' permission turn that permission 'off' on this page. (Actually, I'll take a look at that, but even so, if you have 'Edit TYPE nodes', you run into the same issue.)

[UPDATE: I may have fixed this with http://drupal.org/node/191134 ]

2) This makes no sense. A module can own a vocabulary? In what sense?

A Module can own a Vocabulary. If the domain access module would synchronize the all access information with an (invisible) vocablulary, this information could be used in many ways.

And I don't understand _at all_ what you mean by this:

It would also be a step back towards "drupal core". Which is impotant i think and will increase the acceptance for this module.

The module doesn't break core. It doesn't hack core. It uses core APIs. I _definitely_ think that using an 'invisible' vocabulary is abusing core, and I would never implement such a system.

A module doesn't have to cover all use cases. If you prefer to use taxonomy as an ordering principle, you certainly can, but you might need to use a different module.

Remember, there is nothing stopping you from using Taxonomies in conjunction with this module.

-----

OK, that rant aside, it would be fairly easy to write a Domain Taxonomy module that assigned nodes to taxonomies based on the assigned domains.

I can't begin to write an access control module that's going to satisfy all use-cases. Take a look at the OG section of the discussion here, for example: http://groups.drupal.org/node/6444

What I'm trying to write is a very small, very lightweight module that can be extended to fit different sites.

If you want some help working on a Domain Taxonomy module, just open a new issue.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I have opened a separate issue for request #1, which might be fixable.

See http://drupal.org/node/191134.

derjochenmeyer’s picture

derjochenmeyer commented

Hi agentrickard,

thank you for your detailed answer. Its a great module. My intention is not to criticize it at all. Im playing with it since yesterday and i love it.

The "(invisible)" vocabulary was put in brakets because i would only suggest it as an optional and additional functionality. In this case invisible on the node creation page because the user chooses from the "Domain access options". I also dont trust my users to use Taxonomy correctly to categorize content. But i would like to use it in the backend :-) Thats why i would synchronize it with the "Domain access options".

However, appologies if i was sounding a bit too convinced of my idea, especially with the step back to core ;-) Maybe i have to play more with domain access to understand it better. I read the README.txt and the INSTALL.txt a couple of times. While the most is intuitive there are some things i probably misunderstood. Since its so intuitive i was for example expecting to be able to somehow use views.

What i meant by "A Module can own a Vocabulary" was a bit unclear. I just read the Apress Pro Drupal Developement book:

The module that owns a vocabulary is identified in the module column of the vocabulary table. Normally, this column will contain taxonomy, because the taxonomy module manages most vocabularies.

So as i understand it, also Image and Forum module have vocabularies that are not showing up in the node creation pages in the "Categories" fieldset. There Taxonomy is used to accomplish something very module specific. So i thought it could help to do some sidetasks also here using functionality that core offers.

I think for an experienced drupal developer a Domain Taxonomy module would be an easy task. For me it will be a quite a big challenge. I will give it a try though.

Thanks for your work!

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

My apologies, I had no idea there was a 'module' column in the vocabulary table. You are correct about how that works.

There seem to be two tasks here -- since we fixed the Domain Content issue!

1) Write a Domain Views handler. Though #2 might mean that you don't need it.

For Views, the question is: what do you need to do that you can't do now? One obvious answer is: show nodes from one domain on another domain. But because of how node_access works, you really can't change that behavior if Views implements db_rewrite_sql().

2) Write Domain Taxonomy to store domain grants as taxonomy terms.

You'd need to implement the following:

- An install function to create the domain vocabulary.

- hook_domainupdate() to create taxonomy terms based on subdomains.

- hook_nodeapi() to act on node saves and copy the domain information into the taxonomy system. In this case, the domain information will be in the elements:

-- $node->domain_site (the 'all affiliates' access grant)
-- $node->domains (the normal access grants array)
-- $node->domains_raw (prepared for users who can't select domain options)

I don't know if you'd need any sort of administrative functions.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (won't fix)

Marking this as a won't fix to indicate that I won't be writing this feature.