By mfredrickson on

So, I have been reviewing modules left and right recently, and I am seeing a lot similarities in

These modules are fantastic on their own, but are difficult if not impossible to combine. The problem, as I see it, is that they are each recreating the wheel. Specifically, they are trying to emulate the taxonomy system, each with greater and lesser degrees of success.

Instead, I think they should all use the taxonomy system, and just present different UIs for interaction with vocabularies and terms. Prior to 4.7 this would have been near impossible. After 4.7's form_alter, I think this problem is manageable.

Let me talk about two things that are difficult to do right now, that would be much easier under a unified taxonomy universe.

Example 1: Hierarchical Groups
As I understand it, hierarchical groups are not something that is currently not possible in organic groups. If the groups system were based on a hierarchical "Groups" vocabulary, it would be easy to create children groups of parents. Viewing a single group would be as easy as taxonomy/view/<parent term id>. Viewing all subgroups with a larger group would be taxonomy/view/<parent term id>/all.

Access control could be managed through TAC giving users access to their group's terms only. There might be some need to define "cascading" privileges (i.e. if I have access to parent term A do I have also have access to child term B?), but this can be fixed in taxonomy access, leaving og to concentrate on the UI it presents.

Example 2: Limited access to workflow states
Currently, if I have State1 -> State2, and I need to limit the access to nodes in State2 to just the editors roles (for example), I would have to use an action that changed the node's permission with the node_perm_by_role module. Good luck using taxonomy access or organic groups with this scenario.

However, if each state were a term and the workflow module simply changed the term of the node, Taxonomy access control could do the hard work. If og were under TAC, these two modules can now interact nicely.

These are just two examples. I'm sure there are more.

This proposal is not an easy undertaking. There is a lot of momentum behind workflow and og right now. I understand and respect this, but I think more reliance on the taxonomy system is a good thing. It helps modules use a common system and helps core developers work on improving a system that everyone can use (e.g. nested sets, cached taxonomy look ups, etc).

Even if this doesn't immediately prod the maintainers of these modules to move to taxonomy, I hope I can convince modules developers that are looking at new projects to think about using the taxonomy system more. I know I am.

Cheers,
-Mark

Comments

jasonwhat’s picture

jasonwhat commented

I agree that there are a bunch of modules that have cross functionality. Deeper permissioning should really be a core feature and not just something possible with groups modules. However, I don't think all of this can be done in core. I think a great example of a simple module on the right track is tagnode. Tagnode (like the old clipper module) creates a node and a term that correpsonds with the node. Any other node that is categorized under the tagnode's term becomes attached to the tagnode. Obviously this is a much simpler module than something like OG, but it is a good example of using the existing taxonomy structure to manage relationships, rather than creating new structures.

Here is an example I had recently. An organization wanted groups for chapters. Each chapter has its own homepage within the site, with public and private areas. With a chapter for each state, using roles is not feasible as this many roles would be hard to manage. OG is okay, but it doesn't account for the fact that some content in a chapter is public, while some is private (for members of that chapter only). Thus, I end up creating a taxonomy term for each chapter to display the public content, and an organic group to protect the group only content and provide other group features.

Whenever an editor creates a node they must select their own chapter in the taxonomy term select (not good because they shouldn't be able to select the term for any chapter but their own, it should be automatic that they are publishing to their own chapter) and they must remember to uncheck the public box and check the organic group box. In short, there is no mechanism to restrict editors to posting into their own chapter (group) and maintain access for members only content. This doesn't even touch on the issues if there are multiple chapters in one state or sub-chapters (group hierarchies).


Finding a way to bring all this into taxonomy and traditional access system would be great. I think there are some contributions to OG for managing forums that are moving this direction.

mfredrickson’s picture

mfredrickson commented

As to role: I think roles need to be split into two orthogonal types:

Permission Roles
This role type answers the "what can this user do?" This is the basic job of roles right now in drupal. Can a user edit a blog? Yes or no. Can a user create new groups? Yes or no.
Access Groups
This role type answers the question "where can a user do his/her actions?" Can I do my actions on nodes tagged "Organic Group 1"? Can I tag new nodes "Workflow state XYZ?" etc.

Right now, these two role types are conflated. It can occasionally save some time by limiting the what and where of a single group, but I think this is a small benefit compared the problem you describe, which is increasingly common. (Plus, someone could just write a time saver module called "dual_role_creation" that makes both of these roles at the same time.

Roles are a seriously underworked component of Drupal. There is no API for managing roles, and the exact nature of a role is so confusing we have to use it for both the "what" and the "where" questions.

--

I think I can help in the "right now" with this problem:

nd they must remember to uncheck the public box and check the organic group box. In short, there is no mechanism to restrict editors to posting into their own chapter (group) and maintain access for members only content.

There is a patch to turn off the public box by default:
http://drupal.org/node/28659

Also a good solution might be to make a "Everything" group that emulates public. Force your users to choose a group every time. Add all new users (or anyone who can make "public" posts) to the "Everything" group.

ToddZ-1’s picture

ToddZ-1 commented

The new "Category" module is an attempt to address some of the existing limitations and confusing aspects of taxonomy. I'm still reading up on it, but I wonder how it might fit into your scenarios here.

http://drupal.org/node/39683

mfredrickson’s picture

mfredrickson commented

To be honest, I'm not sure. In my investigations of the category module, I was unable to see why it was significantly different than the book module. I admit I only used the online demo and did not download the module.

What I can say is that the category module "gets it." Instead of creating a category data structure (and the related schema), it uses taxonomy.

edrupalec’s picture

edrupalec commented

Mark,
thank you for a very interesting discussion.

One big drawback with the taxonomy access control (tac) module is that access depends on the very last term. if a node has 10 terms associated with it, whether or not an user can see that node only depends on the 10th term.

if groups were set up through taxonomy, how could this problem be addressed?

-----
Drupal ecommerce, at http://www.drupalecommerce.com is a new site written using language that Drupal beginners and intermediate users can understand. Quick links to "Modules" and "Module Groupings."