TAC as multisite solution -- groups and domains as roles, using roles.

Season's Greetings,

My geek-gene gets a real kick from the idea of '(abusing) taxonomy'.

I am getting my feet wet and asking honest questions here. I'm trying to handle 100 groups, each having 5 or so group roles, spread across about 30 domains.

Why has the Drupal community created Organic Groups as they are? Why this way as opposed to another? I'm sure there are extremely valid reasons. Perhaps the answer helps to understand TAC's use (or abuse) in this tutorial. Perhaps not.

I imagine Drupal as a best-practices learning process. So what am I missing?

As a database person, I would query the idea that a 'role' be named a 'group' (the group entity existing as a role or set of roles). Is that 'normalized' for example? Should a separate key field exist to properly articulate the one-to-many relationship that is called for between groups and group roles, or do roles suffice (as in this tutorial's case)?

Before entering into domain/multisite issues, I can see that either approach offers this as a starting point. However, what makes sense for these two approaches -- roles alone (grouped by naming convention), or roles grouped by another element (i.e. OG/OG_User_Roles)? How are they optimized differently and why? Which approach encourages the right functionality to be developed for open and sustainable social networking, for example? Which will require the most developer time to bring to full groups functionality? Either way, my groups will need multiple roles, and I need a way to list my groups. Can one really escape using OG for grouping users?

If this tutorial is inconsistent with the long-term vision emerging in Drupal (for TAC, groups and multisite), then please say more. What if OG and Domain Access resolve issues with OG_User_Roles and everything moves in that direction -- which seems a strong possibility -- would the above tutorial still be necessary?

Grateful for this!

HowTo: Groups as Roles tutorial
http://drupal.org/node/200631

4. Create user roles - and users.
..."Groups As Roles": there must be a one-to-one relationship between the terms in our Groups vocabulary and corresponding roles. We need a role for each of our groups.

I am concerned with the ability to scale this to organizations that have a large number of groups or where groups are self-assembled. I share all the same requirements as you but having to create a Category+Role for each new group seems like a maintenance nightmare. My organization has over 200 groups, with your schema I will have over 200 terms that must be coordinated with 200 roles "by hand". No thanks!

Lots to say, little time. Thanks for the nice tutorials. I read them but did not test.

You are not the first to suggest that groups should be taxonomy powered. Two smart cookies, Earl Miles and Mark Frederickson have suggested a similar path. See A, B, C. We had more discussion via private email.

It is important to recognize that there is no right answer here. These subtle questions can only be answered by actually building and using both solutions on production sites and evaluating which one makes you contort less.

Here's my breakdown:

Benefits of taxonomy powered groups

1. Less custom code
2. Easy path to nested groups (i.e. subgroups).
3. Taxonomy access could potentially play nicer with other access control modules primarily because they might also need taxonomy flavored control.

These are all significant benefits. 2. is doable in og but the lack of node relationships in core makes it harder. Still, I would like this in the next version.

Benefits to og powered groups

1. Groups are organic.
2. Groups have differing types and fields
3. Groups have custom behavior like moderation, email notification, ...
4. Groups need to be listed (group homepage, my groups, my tracker, rss feeds, etc).

The essential discussion point here is the merit of group as node. I submit that this benefit is enormous. First, we have an easy way for end users to create nodes, according to their permission. We have no such tool for terms. Second, og supports naming multiple content types as 'group' types. This enables you to have different cck fields for different properties of a group. Some group types are casual yahoo groups type groups while another might be a group around a proposed law to congress. The proposed law group will collect and display different metadata. Third, nodes can easily trigger actions.module actions when they are submitted such as email notification and such. Nodes can be put into a moderation queue, and put into a book. Fourth, nodes are easily listed in every imaginable slice and dice with Views module. Since Views2 will support listing of non nodes, this benefit may diminish over time.

The tutorial proposes groups as terms and I disagree with that. The full force of Drupal development is behind nodes. See above. It is foolish to ignore that. The taxonomy module has not substantially changed since 2002 when it was born. It was born a masterpiece for sure, but still its lack of growth is telling. Consider how advanced we are at rendering nodes these days. We have this killer drupal_render() system which learned about node styles in D6. We have no equivalent for terms. Sure it can built, but then you are swimming up river, instead of floating along with it.

Roles versus custom subscriber lists

The tutorial proposes to use roles to collect users and affiliate with a group. Thats fine, but core really hurts us here. We have no strong API for creating roles, or adding/removing users from roles. Lastly, we need a way to remove roles from the UI. If we had all this, roles might be the preferred choice. Note that og does more than affiliate users to groups. We store if a user is an admin in the group and if he wants to receive notifications for the group and so on. So I don't think pure roles will do for storing user+group info. Bottom line - someone go improve the role API!

Question

In the multi-site, what is doing the content restriction so that content from marketing does not show up in finance.local (for example). I did not catch this.

The multiple_node_access patch supports this logic today. And, to be clear, what we need is the option to allow any combination of AND and OR among a collection of modules. Some sites may want:

IF OG or TAC and DA

Others may want:

IF OG AND TAC and DA

Or:

IF OG or TAC and DA and CA

So our code logic should be flexible enough to support that. I think the patch allows for this type of control, if implemented smartly. I went through about three options for OG/DA integration before arriving at this patch.

What you do is add a 'group' element to the $grants array passed by hook_node_grants(). One of the things I like about the patch is that it requires only a very minor API change and does not require any current modules to change at all unless they want to exploit this feature.

See the implementation at: http://therickards.com/api/function/domain_node_grants/Domain

Ideally, as Moshe points out in the patch issue, this behavior is configurable. In the case of Domain Access, we run this check:

And we append the $grants['group'] = 'domain' if TRUE.

The 'domain_access_rules' variable is optionally set through a configuration form, and can only be activated if more than one module implements hook_node_grants().

See the implementation in http://therickards.com/api/function/domain_configure_form/Domain (search for 'node_access_grants_sql').

In the case of TAC or OG, a similar setting could be applied using this logic:

-- Check for the existence of other node access modules
-- If TRUE, allow AND or OR logic to be selected
-- Then, in hook_node_grants(), if TRUE, set 'group' in the $grants array.
-- e.g. $grants['tac']['group'] = 'tac';

A module may declare one or more groups, depending on how many different grants it passes. Each grant not assigned to a group is put into an 'all' array and processed using the current OR logic. Each distinct group is then AND attached to the query as a subselect.

NOTE: One reason this is a patch and not in core is that MySQL 4.0 does not support subselects, and Drupal <= 5 runs on MySQL 4.0 >.

It is also possible that this is a bad approach, and it needs to be tested for scale.

--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3

This thread was started to test whether TAC could be used as the only additional module (together with core Drupal multisite functionality) to provide a sophisticated multisite/group solution with fine-grained access control. The team working on meeting the requirements of an international NGO (www.drupalproject.iofc.org) for multiple domains and groups, with fine-grained access permissions, plus shared users and content across all domains and groups, evaluated six possible configurations. All of them apart from the first assume Drupal's core multisite functionality for that part of the requirement (summary in a moment). The six are:

1. Domain Access + Organic Groups
2. TAC only
3. TAC + OI (Organizational Infrastructure)
4. TAC + OG
5. TAC + a new module based on OG
6. OG only

It should be noted that the modules mentioned in this list are only the modules which control node access. Our 'holy grail' was to have only one such module, which was why we looked carefully at option 2 (see top of this thread). Our final solution, option 6, requires the og_user_roles module but this does not compete with OG for node access.

Readers of this thread may not have time to hear details of the advantages/disadvantages of each solution. So I will summarize how we configured option 6, and why we felt it came closest to meeting our requirements. But first a brief summary of our core requirements.

Main requirements

• Multiple domains built on one codebase, sharing users and nodes across all domains, but with fine-grained administer permissions per domain and group, and for distinct content types.
• In addition to authenticated users, an extra layer of 'network members' (a system/network wide role) with access to additional content across all domains. Both authenticated users and network members to be able to log in on any domain and stay logged in when travelling to another domain.
• Distinction between 'publishing' and 'making public'. We needed a way to publish to various subsets of users, including all network members, without content appearing on a public site.

The OG-only configuration

• Primary multi domain functionality handled by core Drupal. A reminder of the key points:
• A folder for each domain (under /sites) named after the domain/subdomain name.
• The settings.php file in each domain folder amended to set the $cookie_domain to the shared base domain; this allows user to log in on any domain, and to stay logged in when travelling between domains.
• Domain-specific table prefixing for SOME tables (specified in the settings.php file for each domain) - blocks, boxes, menu, variable, cache, cache_menu and user_roles. The first three permit domain-specific blocks and menus, and the last one (user_roles) allows us to assign roles limited to a domain.
• Configuration of each domain is a manual process and includes duplicating/renaming tables, and having to log in to each domain and configure theme etc. In this respect, Domain Access provides some highly desirable functionality for domain creation and configuration, which were reluctant to lose.
• Publication to 'network members' only handled by creating an OG 'domain container group' in each domain to which ALL network members are subscribed in EVERY domain. The effect of this is for content published to a 'domain container group' to be visible to any network member while visiting the respective domain.
• Placement of node content in a domain handled by assigning content to one (or more) group/s in a domain, and by building views which aggregate the content of all groups in that domain. In effect this makes a domain somewhat abstract (in the sense that there is no single assignment that binds all content to a domain) but Views allows us to overcome this limitation.
• Access to, and update permission, for node content configured by membership of a group and, where needed, by user roles within a group.
• Making content 'public' (to anonymous users) restricted to webmasters role; OG configured to make new content private by default, which hides the 'public' checkbox in the Audience box for most users.
• Content sharing achieved by Views which aggregate public content from all domains into a list, accessible only to webmasters, allowing them to edit a node and assign it to their domain. Here we must note a limitation of our solution, a webmaster of one site can edit content created by a user on another site and 'shared' (made available for possible use) across all domains. Domain Access prevents this (something we would have preferred). On balance we decided that in the trusted environment of our NGO, webmasters would not abuse this privilege; additional benefits of editing rights included the ability to correct typographical errors without recourse to the author, and the powerful Node Clone functionality.

Advantages/disadvantages of this solution
Each of the six solutions has its advantages and disadvantages. The main disadvantages of OG only for us have to do with the loss of Domain Access functionality:

• Dynamic domain creation and configuration
• Ability to deny access to node content in some places (our configuration will not show content in the wrong place, but a user who knows the number of a node which is 'public' can access it in the wrong place).

The main advantages for us (some of these would have also been achieved with other solutions) include:

• A domain being the aggregation of all content in its groups allows great flexibility and fluidity, with groups able to form or die or move to another domain or replicate their content elsewhere.
• Only one additional node access module used: reduces problems, speeds up performance, no patching of core
• Easy interface for node content assignment - all done via the OG Audience box (which can be made more user-friendly in a system with 100-200 groups by a combination of contributed modules and a new module).
• A relatively small number of system-wide roles which can be given to specific users in three 'places':
  1. The domain (via domain-specific user_roles tables)
  2. The domain container group (conceptually distinct from other groups in a domain)
  3. A group
• One method of node access configuration to learn, rather than two (the working together of which can be hard to understand fully)
• Multiple content types rather than multiple terms in a taxonomy vocabulary allow more control over content type configuration

We would welcome and be grateful for any further feedback on this solution.

I arrived to the same conclusion for a social community distribution profile i am building located here http://groups.drupal.org/openmusic
for music bands/artists/fans. Essentially each artist/music band is an organic group, and each organic group has the ability -through og_user_roles to assign group specific roles to group members, making them "manager of the band", "band photographer", "band member" etc. I've been following SomebodySysop's progress almost from the beginning and I have to say he has build a very solid and to the point module that is perfectly suited for this situations.