Access Control

First implementation of og_access with ACL

paolomainardi — Mon, 04 Aug 2008 16:25:07 +0000

Hi,

I'm a little bit frustrated by the User access implementation proposed for OG, it's too much complicated and i don't think that TAC/CA/ACL/OG combination with many many many hacks is the right way (but it's a very very good work too).

So, i really need for my project, this simple things:

1) Organic Group
2) User can post in Public or in their suscribed groups
3) AND they must have the possibility to grant other users that can be outside of his group

I don't have need of TAC/CA/ACL all together but only this, i've produced a custom og_access.module, perfectly integrated with ACL, now when i write a post i can select Public or My OG and add grants (view/update/delete) to other users. Nice ?

Can i attach the patch here ? Are you interested in this ?

Bye,

Paolo

Access Control

Language Based Access Control

Tshering@drupal.org — Fri, 20 Jun 2008 06:10:54 +0000

Hello,

I'm building a multi-lingual site, where I would like different translation groups/roles to be able to work on their language (and only their language) to translate source content. In some cases translating in response to content being posted, and at other times originating the content.

Of the current access control methods I've looked at, there are ways to control access based on Taxonomies, Node types, and individual nodes... I may be missing something, but is there a way to control access based on language aside from making people specify the language of the content through taxonomy?

-KT

Translations

Multiple Node Access Logic Patch

somebodysysop@drupal.org — Fri, 09 May 2008 17:54:02 +0000

It appears that agentrickard has created the solution to the problem for which the Access Control Group was originally created: The Multiple Node Access Logic Patch: http://drupal.org/node/196922

I have used this patch to successfully get TAC and OG working together. I'm including it in the next release of OG User Roles (5.x-3.0): http://groups.drupal.org/node/3700

As great as I think this patch is, it probably won't make it into Drupal core, for a variety of reasons.

If you believe in the mission of this group, to create a mechanism in Drupal by which all Access Control Systems can not only simply co-exist, but also respect each other's permissions, then I would ask you to support agentrickard's efforts. He needs folks to not only pontificate and theorize, but test out code.

As many of you know, I came up with a mechanism to make TAC and OG work together over a year ago. The problem with my approach is that it used an unsupported hook_nodeapi('access') and required a heavily customized hook_db_rewrite_sql(). The thought of trying to upgrade to Drupal Version 6.x with this beheamoth was frightening.

What is better about agentrickard's approach is that his integration is based upon the existing Drupal core node grants system. User configured access control logic is introduced during the node_access_grants_sql process.

The most significant argument that has been made against this is that it has a potentially negative effect on performance. I don't doubt that this is true, but then, within the existing Drupal core grant system, how would you ever implement mutliple node access requirements without requiring that users have all possible grants in order to view a piece of content? In short, absent a total re-working of the core system to support multiple node access, you will always have this problem when trying to accomodate more than one Access Control System.

So, if you really need to get multiple access control systems working together, and you want to do it today, this route seems to be a good way to go.

Thanks to all who have supported the efforts here to date. Please continue to do so as that's the only way we're going to effect some positive changes.

Thanks!

Access Control

module-based multiple node_access?

gcassie — Sun, 04 May 2008 15:28:43 +0000

I had a notion the other day of a module to bypass node_access. It seems if you had a module with a very heavy weight and hook_node_access_records, it could fire after all the other hook_node_access_records calls. Then it could:

Copy all the other modules' node_access records into a table of its own with the same structure as node_access.
Set all the other modules' node_access records to DENY for everything.

Then when node_access fires, it could execute arbitrary logic to set its own grants for view, update, and delete based on the other modules' stored settings. Since core uses and OR, all the other entries would be effectively bypassed since they've been set to DENY, and only this module's logic would have an effect.

Might this avoid a core hack? Could it be a way for OG, domain, and workflow permissions to exist on one install? It would have to be restricted to superadmins most likely, because you'd have to write a bit of logic up for each of the grants based on all the node_access-enabled modules on the install. If it works in concept, you could establish a sort of cookbook for different module combinations.

Access Control

Case study: running a small college site with drupal

davidhamilton — Fri, 28 Mar 2008 20:35:36 +0000

Hi folks,

I'm following up on promises I made during the Birds of a Feather sessions at Drupalcon Boston to post a case study of how we're using Drupal at Amherst College. We've developed a module to facilitate hierarchical content creation and permission control that's also of potential interest to folks outside of the academic community.

Preamble aside - about 3 years ago the college decided to fundamentally change the way it was approaching the web, and a little over 2 years ago we started building on top of Drupal. The project had some broad goals:

Find a way to gather together all members of the college community under a common web platform. Faculty, Students, Staff and Alumni were our primary focus, though we've since incorporated applicants.
Change the way the college creates and manages web content. Amherst had been on the Dreamweaver + templates + department directories with shared passwords (!!!) model. We also wanted to get a consistent navigation scheme and thematically similar templates applied to the upper levels of the college's site.
Begin dynamically building the academic portions of the college's website. Course listings, faculty listings, course enrollment listings, and more needed to all be delivered out of data instead of built manually by various academic staff and faculty.
Amherst was disturbed by the legal action Blackboard took against Desire2Learn. We also knew that about 90% of faculty use of Blackboard on our campus was for password protected document sharing. We wanted to move away from Blackboard and replace it with other tools.

A partial list of what we've delivered so far:

Automation of curricular data:

every academic department has a dynamically produced list of courses built from Datatel/Registrar data - example, Asian Studies
every academic department has a dynamically produced list of faculty - example, Spanish faculty listing
every course has a dynamically produced course website with numerous components including course rosters and e-reserves; this is delivered with granular permissions for reading and authoring content for each of the website components. Example - a recent Economics course. A picture of the permission settings for a course:
every faculty member has a dynamically generated ”CV” page which lists contact info, the courses they're teaching, have taught, and (soon) will be teaching. Faculty can add to this material as they like. Example - Dale Hudson's CV

Every user gets some or all of the following depending on role:

A customizable and personalized portal that delivers content specific to their role(s) at the college -- examples being readings and assignments for students, news from their classmates for alums, news from the college, etc. A picture:
personal webspace. Example - Susan Edwards' personal website
professional “CV” webspace if you're an employee, with dynamic content inserted into it (office location, email address, courses taught, etc.). A picture:

Authoring permissions on the various resources specific to their role(s) -- examples: faculty members can edit their course websites, alums can add news to their class year's news page, department coordinators and staff can edit departmental websites, librarians can add e-reserves to course websites, enrolled students can add content to the class blog, etc. There are literally hundreds of groups. A picture:

read permissions on the materials specific to their role(s) -- examples: students can see the e-reserves for the courses they're enrolled in, faculty can review the faculty meeting minutes, etc.
The ability to maintain their personal information – contact info, family history, professional history, personal interests, more (mostly for alums).

Additional features:

e-commerce tools providing features like reunion registration for alums and gifts to the college
a voting tool for trustee elections, faculty committee memberships, and more.

How we did it:

Staff: We have two full time Drupal developers and myself (diplomat/project manager). One of our DBA's spent about half her time on this over the last two years. Our desktop support folks have spent a ton of time on training, representing about 1/2 of one person's time over the last 2 years. Our web designer spent at least half her time on this, and probably closer to 75%.
Process: We opted for a phased rollout strategy, focusing our attention on one college role at a time before moving on to the next, and we've followed a “release quickly, adjust later according to user request” philosophy. Results of this approach have been mixed. We've managed to do a lot in ~2 years, but nothing is ever “complete” and we've often stumbled over unforeseen problems we would have caught had we pursued a more gradual, thoughtful approach. I'm not sure we would change though if given a do-over, because one of the goals was to quickly modernize the college's approach to the web, and a more deliberate approach conflicts with that goal.
Code: The main thing we needed that Drupal doesn't have out-of-the-box was sophisticated hierarchical content authoring with permissions control. To deliver this we built our own module, which we've dubbed “monster menus.” A brief overview:
Content is organized in one or more trees, with each level of the tree acting as a container for one or more Drupal nodes. Nodes can appear in more than one container at the same time, allowing content to be reused without the need to update it in more than one place. The user sees branches of a tree as a menu contained within a block. You can specify the depth of the branch to be displayed in a menu block, and menus can be themed as desired.
Each level of the tree provides an element in the full URL of a given container.
A granular permissions system:
uses a Unix-like system of dependence, where a given user's ability to access one level of the tree depends on his ability at the parent levels; newly-added nodes inherit the permissions of their container, by default
each container in the tree has separate settings for "who can edit its settings or delete it", "who can add sub-pages", "who can assign Drupal nodes to the container", and "who can read Drupal nodes in the container".
includes three types of groups: pre-defined (where the member list is generated by a SQL query), ad-hoc (access to a single container), and manually edited (where one or more permitted people control the membership list). The ability to edit this last kind of group is, itself, controlled using the same groups-based permissions model. This allows maintenance of access control lists to be distributed to any number of trusted users.
because this scheme does not use Drupal's built-in grants tables, it scales well to many thousands of users, groups, and nodes
Menu settings, allowed themes, and allowed node types can be assigned per container, and cascade downward in the tree.
Each user has his own "homepage" space where he can create new containers and content
Based on user feedback, we found it best to change certain terminology, and remove a few node options, thus simplifying the interface a bit. This would be optional, were we to release the module to a wider audience.

I've recorded a ~10 minute screencast which runs through most of the features discussed above, which you can review here.

We've also done a lot of work on our own profile module (eduprofile), which draws on our backend (Datatel) to display users’ biographical, curricular, and personal information. It lets them edit various portions, depending on their role, and choose which other roles can see each portion of their data. An important distinction is that these are not Drupal roles, they're created dynamically from institutional data.

Areas we've struggled with:

search. We've researched integrating with a Google Mini and, once time permits, will go that route. For now, we're not too happy with our search relevancy, and we're only searching across publicly available content.
data integration. This has nothing to do with Drupal per se, but in terms of time spent, it's been one of the largest time sinks for us.
We had to touch core. We have to do integration work when we adopt modules from contrib. We were able to back much of our code out of core when we ported to Drupal 5, and we're hopeful we can back all the way out when we port to Drupal 6 this summer.

What we're working on now:

Moving the last of our old, static content into the system
updating our codebase to Drupal 6
calendaring for all users, built using a customized version of the events module
quiz tool and gradebook to supplant most of the remaining Blackboard use on campus.
migrating our library site
enhancing our portal to incorporate more features (calendar display, profile management, etc.)
integration with Views and CCK. When we started these tools didn't fit our needs. They do now.

At present both of our modules are tightly coupled to our Datatel implementation. At Drupalcon there was some interest in how our system worked. We also attended a session led by the Development Seed folks where they presented an alternative approach to some of the issues we worked to resolve, and were struck by one of the things they said at the end, which (paraphrasing) was, “So, we invented a solution off on our own, and now we want to know what the Drupal community thinks of it as an approach.”

We have the same question. We could work to decouple our code from Datatel and share it, but that represents a significant time investment for us, so we're curious to hear whether folks have more than an academic interest in what we've built.

Beyond this case study, after we've finished our migration to Drupal 6, we'll put up a test machine so folks can kick the virtual tires and get a sense of how this works. At best we'll get to that early this summer. In the meantime, I am happy to answer any questions folks have, and if needed I can screencap/screencast additional aspects of the system. We can also work to get a case study of monster menus with more detailed information on how it works up on drupal.org if folks would find that useful.

Access Control

Partial forum sharing

Miraploy — Sat, 08 Mar 2008 21:06:53 +0000

Here's my setup: I have a network with different forums and different content but shared users on one codebase on the same database with different prefixes.

What I'm hoping for is a way for all of these sites to share the same 'off-topic' category but different overall forums. What's the best way to achieve this? Thanks.

Access Control

Contract PHP Developer with Drupal Experience Needed to Complete a Website Redesign | Ripple Effects Interactive

zdbraham — Fri, 07 Mar 2008 14:42:37 +0000

Overview

Ripple Effects Interactive (REI) is looking for an independent contractor or service to provide short-term (30 - 90 days) help with a client’s Drupal-based social networking web site. The position will require approximately 20-30 hours a week, possibly more.

Project Description

We are redesigning a social networking website that is currently using Drupal 4.6.2. We would like to continue to leverage this version of Drupal and essentially need to apply a new GUI, update the navigation schema, and add some new custom features such as:

Customized summary nodes where we’ll aggregate content to specific landing pages (news & stories)
Development of new pages for details of news & stories

To date, REI has completed UE, interface design, and template coding and can provide the following:

Link to existing site before development begins
Approved wireframes for redesigned site in either Visio or .PDF format
Coded templates written in XHTML 1.0 Transitional and .CSS 2.0

Qualifications

Knowledge of Drupal Theming and experience with the creation of page templates and node templates
Basic Unix skills
Proven experience with similar web-based projects

If interested, please send resume to: jprzybysz@r-effects.com

Pittsburgh and Southwestern PA

programmer with drupal experience | BPA

bpawy123 — Fri, 22 Feb 2008 23:14:30 +0000

I have a project that has been started and the current programmer is too swamped at the moment. He will be willing
to work with you once he finishes out a current project.

We are under a deadline and need to get the site built out. Must sign an NDA prior to getting the full site description.

Details:
1) Html and design work is complete.
2) Partial site has been built.
3) Required back end where corresponding consumer Inputs (answers to questions etc.) will generate outputs in a Personal Plan / Format for the person.
4) Project is Patent Filed.
5) Site has a non-profit side to it, but will lead to revenue.

We would like to complete the build out in order to populate the site with large bought data files within 30 days. We plan to soft launch asap and to do a full
launch in Aug of this year.

Please reply with past data intense sites that you have built out from start to finish.

Reply to webyaaba@yahoo.com

Semantic Web

TODO list: Eventual Version Control migration for drupal.org

hunmonk — Thu, 10 Jan 2008 17:14:55 +0000

This is a loose checklist of items that need to be taken care of to get Version Control API working on drupal.org.

NOTE: This effort has been postponed until after the d.o is upgraded to D6. There's too much here and the versioncontrol* suite is just not yet ready for prime time.

script for migrating from cvs module to versioncontrol_cvs -- in progress
script for migrating from cvs module to versioncontrol_project -- done, but could use more testing
http://drupal.org/node/216371 -- Move item handling and commit branches into the API module -- in progress
http://drupal.org/node/216373 -- Provide direct hook access to the commit retrieval query
http://drupal.org/node/216375 -- Port Version Control API & friends to Drupal 6
http://drupal.org/node/208476 -- add 'commit' as a valid GET arg -- done, but mostly deprecated by the following point:
http://drupal.org/node/209402 -- add legacy 'cvs' menu path, to prevent link rot
http://drupal.org/node/229350 -- Extend the CVS backend so that it supports the optional API function get_directory_contents(), so the release node integration can determine whether or not to package files of a specific branch or tag.
release node conversion
Port the package release scripts to use the new infrastructure
Port or rethink the Form API magic that transforms the harmless file-based release page into a multi-form CVS release drupal.org specific form monster
install CVS dummy repo at http://project.drupal.org
full test install on p.d.o

Access Control

What to do about node_access_rebuild()

agentrickard@drupal.org — Thu, 03 Jan 2008 20:22:22 +0000

So I am researching Taxonomy Access Control (TAC) and Domain Access (DA) integration (though this applies to Organic Groups (OG) and other modules as well). And here's the problem.

node_access_rebuild(), as far as I can tell, is only designed to work with a single access control system.

When node access modules are enabled and disabled, this function is typically invoked. (As demonstrated by the node access example module.

Problem is this first line of the function:

<?php
function node_access_rebuild() {
  db_query("DELETE FROM {node_access}");
?>

Well, this is great if OG is the only node access module that you use. But if there are existing node access records, they get deleted as well.

DA, for example, stores all of its access records in the {node_access} table. It loads them onto the node during node_load(). If this DELETE statement did not exist, then when node_access_rebuild() finally loaded and re-saved the nodes, existing DA rules would be preserved.

I see two obvious paths to solving this problem. One I like; one I do not.

1) Make node_access_rebuild() more selective, like cache_clear_all(), in what it chooses to delete from the {node_access} table. If your module is being uninstalled, you might do this:

<?php
function mymodule_disable() {
  node_access_rebuild($remove = array('my_realm', 'my_other_realm'));
}
?>

And then we modify node_access_rebuild() to account for this.

<?php
function node_access_rebuild($remove = array()) {
  if (empty($remove)) {
    db_query("DELETE FROM {node_access}");
  }
  else {
    db_query("DELETE FROM {node_access} WHERE realm IN (".  implode(',', $remove) .")");
  }
//...
?>

I think this is the preferred solution, but it is an API change and would require coordination across contributed modules to make the change work.

2) Store your node access data in a separate table, so that it is not destroyed by node_access_rebuild().

I thought about this approach for DA, and decided against it because I did not want to store the same data in two places.

Am I now going to have to re-think that decision?

Access Control

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

freeburj — Sun, 16 Dec 2007 20:27:18 +0000

There's a new tutorial at http://drupal.org/node/200631 which is a different approach to Taxonomy Access Control than I have seen, a very different approach to Groups (as a concept), and multiple Domains (hence a multisite solution). I am trying to discern what is going on with og, mulltisite, domain access, and TAC generally.

This tutorial suggests similar functionality to the combination of Domain Access module with Organic Groups, but without either and promises to offer more fine grained control over permissions, although the OG_User_Roles module is perhaps offering similar functionality. It would be interesting to link that concept of a group (i.e. AccountTypes module?) to an OG. How does this approach sit with the OG User Roles people? Does it offer any unique functionality?

The tutorial looks really interesting, although I'm sure that building UI modules will be needed (and perhaps other OG like modules as well). My question for those who know the OG_User_Roles module, what are the advantages to sticking with OG as opposed to a completely new concept of groups? And regarding the Taxonomy Access Control module, what is the maximum number of suggested roles which Drupal is optimized for?

It's an interesting approach to skinning the multisite problem. What do you think?

Seasons Greetings!
ps. sorry for cross-posting similar questions with taxonomy and multisite groups.

Taxonomy

Request for comments -- Setting OG group defaults on a group type by group type basis

billfitzgerald — Sat, 17 Nov 2007 00:44:42 +0000

Currently, within OG, all the group settings are set sitewide for all types of group nodes. We are looking to implement group type by group type default permissions to allow for different types of groups within the same site --

We will be working out a solution to this issue and releasing the code back as a contrib module -- however, before we start coding we want to get some feedback/see if anyone else was thinking along similar lines.

The issue is here: http://drupal.org/node/192933 -- please centralize any discussion on the issue queue.

Cheers,

Bill

Access Control

Least permissions and node_access

agentrickard@drupal.org — Tue, 13 Nov 2007 15:24:50 +0000

OK, so I'm working on integrating Domain Access with OG.

Problem is, the current node_access system uses OR based permissions. What I really need is the option to set AND based permissions. For example:

-- Current node_access rules

return TRUE IF (og == TRUE) OR (Domain Access == TRUE);

-- Desired rules

return TRUE IF (og == TRUE) AND (Domain Access == TRUE);

See http://drupal.org/node/191375 for a full discussion and some possible options.

To summarize, I'm thinking about rewriting the node_access function and adding a hook_access_logic() function to allow for this type of granularity.

There is also a related problem that node_access checks don't run if $node->status == 0 -- which is a problem for my use case.

Multisite

Domain Access uninstall and update questions

agentrickard@drupal.org — Sat, 10 Nov 2007 02:23:03 +0000

OK, beta6 is out and the release is looking pretty good.

But I introduced the Domain Prefix module -- it creates a UI for dynamic table prefixing. So, for example, each of your subdomains can have a different watchdog table. The $db_prefix array is dynamically set on bootstrap.

Two big issues -- notwithstanding the lack of pgSQL support, which I'll get to shortly.

I have not found a way to run a function any time hook_uninstall() is run.
Attempts to add a #submit handler using hook_form_alter() failed. As a resut
I may have to create an admin page for uninstalling domain_prefix tables.

This is important, because if you uninstall a module that has prefixed tables, I need to delete those tables as well.

I also failed to find a way to automate the update.php process -- hook_form_alter()
also fails to add a #submit handler in that case.

Same thing here; the update.php script works for each subdomain, but you should not have to run them all manually.

Anyone know how these two issues are generally handled in a MultiSite setup?

Multisite

Domain Access

agentrickard@drupal.org — Thu, 04 Oct 2007 21:12:56 +0000

For a project, we just came up with another way to skin the multisite problem.

Domain Access is a node access module that enables multiple sites to be run from one installation.

The beta has been released.

See the module in action at http://skirt.com/map

Multisite

Help needed understanding Access Control in OG

tachekent — Mon, 27 Aug 2007 23:48:17 +0000

Hello,
I'm here because it seems like the only place I am likely to find some help with Access Control, having scoured the internet for help elsewhere...

I just set up OG on my 5.1 installation and although I have the groups working nicely (well, single group in my case), I can't for the life of me work out how to restrict access to either the individual posts, or the group homepage. In fact, when I enable access control in the OG settings, both my group and the posts within it suddenly become editable by anonymous/unauthenticated users. I have scoured the settings setting everything to be as private as possible, but with no joy. Is it possible that I'm missing some fundamental point?

I have a site full of open content with a few bloggers and content editors. I need one private area restricted to 2 users (as 2 roles). One role has read access only, the other has read/write access. I don't need any per-node per-user access, but I do need that part of the site to not be open to the public.

Apologies if this is the wrong place to ask - do tell me where to go.

Thanks

Dorian

Access Control

Addition of permission for read/write ability based on topic/blog entry for each user

mnjose — Mon, 13 Aug 2007 11:03:51 +0000

I am in involved in a customization of Drupal 5.2 for our company. I need the following things to be
done:

When a user creates a blog or a forum topic, he/she needs controls to give access to other users
who would be able to read the blog, read & reply comments etc for each blog/forum topic. The access
control should be in the format of a) Public or Private b) Company c) Department/Division d) Individ
ual.
Any reply comments or new creation of blog/forum topic should be send as emails to the particular
user email ids as in the case above.

Please help me in this issue as soon as possible. Thanks for your prompt help.

Regards,
Mnjose

Access Control

Using Content Access and ACL with OG User Roles

somebodysysop@drupal.org — Tue, 31 Jul 2007 17:58:27 +0000

The following documentation was originally written for OGR releases prior to 5.x-3.0. As of OGR Release 5.x-3.0, the "Multiple Node Access logic patch" http://drupal.org/node/196922 is used for TAC/OG/CA/ACL Integration.

As of this writing, I know that CA (Content Access) and ACL (Access Control List) now work with TAC/OG Integration http://groups.drupal.org/node/3700. But, because of the new way this integration is achieved (using the multinode_access table), there are now a variety of ways you can now configure access.

This is complicated stuff, but I'm going to try.

Multiple Node Access Logic

As of OGR Release 5.x-3.0, TAC/OG Integration is achieved by configuring the new "multinode_access" table for the logic you desire between the access control systems. This is the logic recommended for TAC/OG Integration:

(all OR og) AND (tac) OR (ogr)

This says that I always want og and tac rules integrated to respect each other, but they can be overriden by ogr rules. I explain here http://groups.drupal.org/node/3700 what I mean when I say "integrated to respect each other".

OG User Roles now supports these two modules:

Content Access: http://www.drupal.org/project/content_access
ACL: http://www.drupal.org/project/acl

These modules allow you to custom define roles and/or users who can access particular nodes.

In order to add them to our TAC/OG Integration, I recommend this:

(all OR og) AND (tac) OR (ogr) OR (ca) OR (acl)

This says I want tac and og rules always integrated to respect each other, except when overriden by ogr, ca and/or acl rules. If node has a taxonomy term, belongs to a group, and has some content_access permission, a user must have either the group AND taxonomy permissions OR the content_access permissions OR the ogr permissions to access the node.

Now, it's possible to look at this another way:

(all OR og OR ca) AND (tac) OR (ogr) OR (acl)

This says I want tac and og AND ca rules always integrated to respect each other. So, if node has a taxonomy term, belongs to a group, and has some content_access permission, a user must have ALL of these permissions to access the node, not just one or the other, OR the acl permissions OR the ogr permissions.

Configuring TAC/OG/CA/ACL Integration

The following discussion assumes you have, in addition to OG User Roles:

installed both Content Access and ACL modules as well as Taxonomy Access Control (TAC)
you have installed the "node.module.multinode.patch" http://groups.drupal.org/node/4026 provided in the OGR 5.x-3.0 or higher release download
turned on TAC/OG Integration in OGR Settings http://drupal.org/node/163567
created a content type called "Document". You can use any content type you wish, but for this discussion and testing, we've created a content type called "Document".

Configuration:

Go to OGR Settings Admin->Organic groups->Organic groups user roles and click on the "Multinode access UI" tab. You should configure this screen exactly as you see below:

Configure your screen exactly as you see above, and click on "Save changes" button. The above creates the following logic:

(all OR og) AND (tac) OR (ogr) OR (ca) OR (acl)

If you desire another logic possibility but aren't sure how to configure it, please post a support request to OGR Issues: http://drupal.org/project/issues/149373

Next, configure "Document" content type (assumes you have already created it):

http://www.yoursite.com/admin/content/types/document

Home › Administer › Content management › Content types

Click on "Access Control" tab for this content type:

http://www.yoursite.com/admin/content/types/document/access

From this screen:

Enable per node access control settings
Uncheck all roles

"Document" content type is now set up to use Content Access.

You should repeat this process for every content type used on your site that should respect this multinode access logic configuration.

Note: The following original documentation steps are recommended, but required

To be honest, I am no longer sure that the following is required as it once was. The new integration architecture appears to allow you to support CA and ACL with or without TAC.

I'm leaving this documentation just to be on the safe side. But, I suggest you play around and see what works best on your site.

I create a "Document" vocabulary and add the "Document" content type to it.

Home > Administer > Content management

I then use the "add terms" link to add a "NONE" term to the "Document" vocabulary.

Using Taxonomy Access Permissions (TAC), I grant NO role access to this term (except for privileged "Admin" users). This means that any node you assign this term to will not be viewable by anyone. This is the recommended category to use for content for which you intend to use Content Access (i.e., assign customized permissions).

You must do this because you cannot use Content Access to revoke permisisons granted by TAC. However, you can use Content Access to grant permissions to content that TAC does not grant permissions to.

Home › Administer › User management > Taxonomy Access: Permissions

Note: Your Admin role(s) should be given List/Create permisisons here for "NONE" term.

In: Home › Administer › User management > Roles:

Give your Admin users permission to grant content access.

http://www.yoursite.com/admin/user/roles

Gave "Admin" and "GroupAdmin" roles these permissions:

grant content access

grant own content access

These are my Admin roles which can create Content Access nodes. These roles need to be able to List/Create "NONE" term (use Taxonomy Access: Permissions).

Usage:

It is first important to remember that if you want to create custom access to a node you create, that node must NOT have access granted by a vocabulary term. From a technical standpoint, Content Access and Taxonomy Access (TAC) do not work together. So, you can't, for example, assign a node a vocabulary in which TAC allows Role A to view it, then try to use Content Access to restrict Role A from viewing it.

In order to use Content Access, you must assign the node for which access is to be customized to the "NONE" category (you have used TAC to grant NO users access to "NONE" content, except for Admin users). Then from the node's "Access Control" tab (which will appear once the node is submitted) you assign what roles and/or users can view/edit/delete the node.

To create a node with customized content access (using the "Document" content type):

Click on "Create document" link from Group menu.
Create node as usual, except for "Category" select "NONE". Click on "Submit".
At this point, no one can see the node but you.
When the node is saved, you will see an "Access Control" tab next to the "View" and "Edit" tabs. Click on "Access Control" tab.
You will see the "Role access control settings":

Below that you will see the "User access control lists" (ACL) section which has the individual Grant view/update/delete lists. Here is where you enter invidual user IDs to grant a particular permission for this node:

On this screen, you can select the roles to give view/update/delete permissions for this node. Or, you can enter the users to grant view/update/delete permissions for this node.

If you make any changes to this screen, don't forget to click on "Submit".

Don't forget that if you add users to the ACL using the "Add User" button, you must still click on the "Submit" button at the bottom of the screen for your entries to be valid.

Access Control

Overriding taxnomony_access_db_rewrite_sql()

somebodysysop@drupal.org — Sun, 22 Jul 2007 21:57:18 +0000

I've posted this in the Drupal Forums, but want to post it here as well.

As you know, I created patches to the node, og, and taxonomy_access modules which allow them to work together: http://groups.drupal.org/node/3700

What I want to do now is start removing some of these patches by putting the functionality I need into one separate module.

First up: taxonomy_access_db_rewrite_sql(). Curently, I patch this function in order to get the taxonomy_access module to display terms and nodes while respecting OG access control. What I would like to do is take this patched code, put it into another module, and have that module override the default taxonomy_access_db_rewrite_sql() function (therefore removing my need to patch it).

Put another way, I would like to have the db_rewrite_sql() function of Module B override (not add to or augment, but replace) the db_rewrite_sql() function of Module A.

Is this even possible? And if so, any suggestions on how would I go about doing it?

Thanks!

Access Control

OG User Roles now official Drupal Project

somebodysysop@drupal.org — Tue, 05 Jun 2007 19:45:25 +0000

The OG User Roles module is now finally a Drupal project: http://www.drupal.org/project/og_user_roles.

The TAC/OG access control has now been added to the og_user_roles module, and the module is now required for implementation of this functionality. The TAC/OG patches are now located here: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop... and have now been modified to reflect this change.

Access Control

Another aproach

neurojavi — Mon, 28 May 2007 23:41:01 +0000

Hi:

I've read the posts about having TAC and OG access control systems working together...
I think you have done a great job with t¡hose patchs but I like to avoid using patch as much as possible so I have been thinking in a way of doing the same with existing modules...

Modules used:
- OG promote
- TAC
- OG
- Node Auto Term [NAT]

The idea is to use the way TAC works with multi term nodes. From admin/help/taxonomy_access:
"The DENY directives are processed after the ALLOW directives. (DENY overrides ALLOW.) So, if a multicategory node is in Categories "A" and "B" and a user has ALLOW permissions for VIEW in Category "A" and DENY permissions for VIEW in Category "B", then the user will NOT be permitted to VIEW the node. (DENY overrides ALLOW.)"

Think of this as an logical AND of permissions (ALLOW=1/DENY=0)

Procedure:
First we need to create a vocabulary named Groups in which the terms would be the different groups names.
We need to activate this vocabulary for all content types planned to be used in groups.

For each new group we need to take the following steps:
1.- We create a term in Groups vocabulary for each new group created (this can be automated with the NAT module by creating a term in Groups vocab for each node of type Group created).
3.- We create a role for each new group created (this can't be automated)
4.- We go to TAC an set permissions for the new role to deny all actions in all terms but its own term (we can set the defaults to deny all to allow automatic deny of all actions in future groups), so we only have to change it one time.
5.- We need to tag each node created in the group with the corresponding Groups vocabulary term.
6.- We can now assign all the other taxonomy terms we want...

This way the TAC permissions given to regular taxonomy terms would be ANDed with the permissions for the Groups term and this would result in any user who access a group node to be forgiven to do any action if it doesn't belong to the group.

This is only an idea for discussion... I haven't tried it.

If this is feasible, we can think in a solution to automate all the process.
Perhaps with a modification in OG to allow optional creation of a term (if we don't want to use NAT) and a role for each group (and setting TAC permissions) plus a way to do automatic tagging of the nodes attached to an OG would be enough?
Or perhaps it would be better to do it in a new module to avoid unneeded add dependencies to OG.

Bye.-

Access Control

Helpful hint to access control module users

jlmeredith — Mon, 28 May 2007 11:55:06 +0000

I am reporting some findings that I hope will help others who decide to try any access control module currently available to Drupal 5.1 or earlier.

There is currently an issue in the 5.1 build of Drupal which will cause a site with high numbers of nodes (4000 in my case) to error out when rebuilding node access permissions or when enabling / disabling a node access control module. This error is due to node_access_rebuild() calling node_load() and loading every node into cache thus causing an out of memory error. This occurs not only when using the rebuild permissions function in Content Management -> Post Settings but also anytime the node_access_rebuild() function is called such as when enabling or disabling access control modules.

The patch for this issue can be found here: http://drupal.org/node/108752 , or users can update to the current HEAD version of 5.x for the fix. There are plans to further address the issue in 6.x via a batching process.

It would be nice if module developers would include some information in the module documentation specifically about this issue. I believe after reading many different memory error issues throughout DO, that this is a big contributor to many mystery error issues.

Thanks

Relationships & site structuring

Openmusic:a barter Social Network for Musicians, Bands and Fans

christopher_skauss@drupal.org — Thu, 24 May 2007 22:50:34 +0000

Greetings fellow Drupallers!
I began working on OpenMusic, a social network that aims at letting fans help music artists. By giving appropriate roles to its fans - thus getting them involved - an artist can build a network of valuable friends where each can provide a service to help the artist.
I've been in a band many times ( and still am!) and I've seen how fans crave to be involved into bands in one or another way. Designing posters, building websites, making a connection to a local radio station, giving haircut advices each fan can throw in his own 2 cents. What we all need is a platform to allow us to find each other, discovering new music in the middle, making successful gigs and throwing parties. It sounds so much fun, it even gives me the illusion that over there music could eventually be Free.

Now that I finished drooling, on to the serious part. Your opinion is deeply appreciated in forming a framework of functionality for the following diagram:

I've been striving to work out the best approach but I am always at dead ends. Organic groups, buddylist, taxonomy access, a more granular form of access control, somebodysysop's og_user_roles, which of all!? How can a user be a fan of Band A and simultaneously be Band A's manager. From what I've gathered so far, organic groups seems to be the best approach, where a generic og member is a fan, and roles specific to each group tell what kind of a fan one is. A band's manager should be given the right to publish an event node to the band's og page, a band's graphic designer to publish an image node, much like a music artist should be able to create an audio node in his bands og page.

Am I missing something here? Can this be done without organic groups? What about artists that are not bands, how can they have fans?
Could all this ever be made into a distribution profile?

Social Networking Sites

Content Access 1.0 released!

fago@drupal.org — Sat, 19 May 2007 17:15:56 +0000

Yet another node access module..
Read more at http://more.zites.net/content_access

Access Control

How to Make OG and TAC Work Together: Step 3

somebodysysop@drupal.org — Fri, 11 May 2007 19:51:06 +0000

The patch for modifications I discussed in TAC/OG Integration Step 2 (http://groups.drupal.org/node/3700) is located here as well as the latest OGR distribution:

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop...

Instructions for OGR Release 5.x-3.0 and higher

Once OG User Roles module is downloaded and installed, you must:

Install the node.module.multinode.patch

This patch is included in OGR Release 5.x-3.0 and higher. It is also available from here:

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/somebodysysop...
http://ftp.scbbs.com/pub/drupal/TAC_OG/

Download and place this patch file into your Drupal web site "/modules/node"
directory. Then, execute this command:

patch -p0 < node.module.multinode.patch

Go to OG User Roles settings and place check in "TAC/OG Access
Control Integration" ("Integrate TAC and OG Access Control").
Go to OG User Roles settings and click on the "Configure multinode UI"
tab. You will see the "multinode_access" table listing of node
grant realms. You need to make the following changes to this table:

   ogr_access
   ==========
   Place check in checkbox next to "ogr_access" Realm name.
   Enter "ogr" in Group column.
   Select "OR" as Logic.
   Select "1" as Weight.
   Select "0" for Check.
   term_access
   ===========
   Place check in checkbox next to "term_access" Realm name.
   Enter "tac" in Group column.
   Select "AND" as Logic.
   Select "0" as Weight.
   Select "0" for Check.
   All other realms should remain unchecked.

See the screenshot of what your table modification should look like: http://drupal.org/files/OGRConfigureMultinodeUI.jpg Click on "Save changes" button to save your changes.

If you do not see ogr_access realm in multinode access table, see: http://drupal.org/node/300421

How to apply patches: http://drupal.org/node/60108

Instructions for OGR releases prior to 3.0

Previous to release 2.0 of OG User Roles, there are were 3 patches:

og.module.TAC_OG.patch
taxonomy_access.module.TAC_OG.patch
node.module.TAC_OG.patch

As of OG User Roles release 2.0, but previous to 3.0 there is only one patch:

    og_user_roles.nodeapi_access.patch

As you read in Step 2, there were several modules that I modified for my own customizations, but the OG, Node and Taxonomy Access Control modules were the basic modules that needed to be modified in order for TAC and OG to work together. In release 2.0 of OG User Roles, I managed to put most of these modifications into the OG User Roles module itself.

The only remaining modification was to the node_access function in the node.module, to handle the updated process of access control. For this, I use the Nodeapi Access patch, which is discussed in length here: http://drupal.org/node/143075 and here: http://drupal.org/node/122173. It is my hope that this patch will make it's way into Drupal 7 core.

You can also retrieve this patch from here: http://ftp.scbbs.com/pub/drupal/TAC_OG

And, it is included in the OG User Roles 2.0 and higher distributions.

Access Control

How to Make OG and TAC Work Together: Step 2

somebodysysop@drupal.org — Tue, 17 Apr 2007 18:29:35 +0000

Notes as of OGR Release 3.0 and higher

This has been a long process. In short, I've been able to get TAC (Taxonomy Access Control) and OG (Organic Groups) working together with OGR (Organic Groups User Roles). The history of this process is discussed below under Notes previous to OGR Release 3.0. I feel it is important to maintain this documentation. If you are considering using TAC/OG Integration, you should read it to understand the background and important issues of this project.

The latest progress on this project involves use of the "Multiple Node Access logic patch" which is discussed at length here: http://drupal.org/node/196922

Instructions and patch locations for installing current OGR TAC/OG Integration are located here: http://groups.drupal.org/node/4026

Please submit any questions you may have regarding this project in the Issues for OG User Roles: http://drupal.org/project/issues/og_user_roles?categories=support&states...

Notes previous to OGR Release 3.0

At first, I was going to provide the patches for the module updates in this step, but this is a big step because here is where you modify all the access control mechanisms. I wanted to break this down into smaller steps, but it's pretty difficult since all the changes have to be done at once. So, I decided to make this step an educational step designed to share my philosophy and approach to the access control changes I made, and how they came about.

To recap, I needed OG (Organic Groups) and TAC (Taxonomy Access Control) to work together. In the default Drupal access control setup, if you have a node that is in a group and has a particular taxonomy, any user can see the node if he EITHER belongs to the group OR has access to the taxonomy term. What I wanted was a mechanism that only allowed access to the node if the user BOTH belongs to the group AND has access to the taxonomy term.

This discussion with the TAC maintainer was very instrumental in pointing me in the right direction to achieve my goal: http://drupal.org/node/122712. It also helped to make clear what I was dealing with:

There are basically two major elements of access control: grants and permissions (this is my terminology). Grants are things like "grant_list", "grant_view", "grant_update", "grant_delete", and are generally assigned through taxonomy. Permissions are assigned to roles via the Drupal "access control" menu, and typically are things like "access content", "create document content", "administer organic groups".

There are three functions which are primarily used to determine what access users have to content: "user_access" (from the user.module) and "node_access" (from the node.module) and db_rewrite_sql (a module hook). "user_access" deals primarily with permissions but "node_access" looks at permissions and grants. db_rewrite_sql handles access with respect to node listings.

Note: I know that there are those of you who are going to mention things like "taxonomy_access_node_access_records($node)" and "hook_node_access_records($node)" and "hook_node_grants", etc... But, not matter how I look at it, the access control always seems to come down to "user_access", "node_access" and "db_rewrite_sql". Bringing back a load of grants with no way to establish which have priority over which just doesn't seem to solve the problem.

So, to recap, "create" access is usually determined by "user_access" function. Node "view", "update" and "delete" access by "node_access". And, node listing by "db_rewrite_sql". So, with respect to access control modification, these are the Drupal core functions I need to be able to change.

I have already modified "user_access" with my OG User Roles module which allows granting of role permissions by group. The next step was to modify "node_access" for viewing, updating and deleting content while respecting both OG and TAC grants. Enter the "Extensible Node Access/Authorisation Capability" patch: http://drupal.org/node/122173. Read up on this because this is the core of my modifications.

Using the "Extensible Node Access/Authoriisation Capability" patch, I was able to modify "node_access" to use a "nodeapi" hook that allowed me to write access control code that made sure that both OG and TAC grants were respected.

If Drupal node listings utilized "user_access", my problem would have been solved right here. Unfortunately it does not. For node listing access, I had to look to "node_db_rewrite_sql". This seemed crazy to me: After all the work I did with the access nodeapi hook, I still had to turn around and basically re-write node_db_rewrite_sql to do the same thing the access nodeapi was doing. However, there was no way around this: I needed to modify this function if I wanted my node listing to reflect both OG and TAC access controls. Actually, Drupal states (in the "node_access" comments) that this seemingly inexplicable inconsistency is for performance reasons, but I think this is what makes it near impossible for contributors to write modules whose access controls respect each other and work in concert. This is my opinion only.

After modifying "node_db_rewrite_sql" for the new access control, I pretty much had everything working, with the exception of one problem: My vocabulary pulldown select lists within nodes didn't seem correct. They were either missing vocabulary terms, or listing terms that should not be there. The taxonomy pulldown lists are created by "taxonomy_form_alter" (in the taxonomy.module), but if you have the taxonomy_access.module (TAC) installed, the access for this list is controlled by "taxonomy_access_db_rewrite_sql". So, I also needed to modify the "taxonomy_access_db_rewrite_sql" function in the Taxonomy Access Control module to respect OG and TAC together.

After these modifications, I had a system that worked as I wanted: People can only see the content they have access to see. I can have dozens of groups without having to define dozens of dozens of roles - each group can use the same roles because users role access can be defined by group (or site wide). Furthermore, within the groups, I can define further restrictions to content using taxonomy.

The only drawback to this system is that all content must have taxonomy and either belong to a OG group, or be explicitly marked as "public" to be seen. Obviously, these modifications are for a site that is OG-centric and security minded. If your site does not primarily consist of multiple groups which contain highly private content, then you should not waste your time on these modifications.

Below is the list of modules I have installed, and the modifications to each that I have made. These are notes I made as I went through this process. Essentially, the core modifications are limited to just three modules: node, og and taxonomy_access. This is so you will know what to expect when you get to Step 3 - the patches:

• Forums
(None of these modifications required for access control)
Modified: theme_forum_display($forums, $topics, $parents, $tid, $sortby, $forum_per_page) Added functionality to use content submission page CSP “addform” node to create forum topics. Also put in group context on group forum “General discussion” page. (These are customizations and not necessary for access control)

• Node (updated).
Modified: Installed Extensible Node Access/Authorisation Capability patch: http://drupal.org/node/122173 in node_access() function.
Modified: db_node_rewrite_sql(),_node_access_join_sql(),_node_access_where_sql()

• NodeFamily
Had to modify php.ini: allow_call_time_pass_reference = On

• NodeProfile
Tutorial here: http://drupal.org/node/130489 and here http://drupal.org/node/130756
To display node profiles as profile categories (in “my account”): http://drupal.org/node/84541
Had to apply the patch as well as implement modification discussed in #31.
Permissions required to get one role to edit all uprofiles, and user to only be able to edit his own: authenticated role: ignore VUD|Create/List checked. User Profile Admin role: allow VUD|Create/List checked.

• OG
Ran into problems here: http://drupal.org/node/122385 and here: http://drupal.org/node/116756
Using TAC, if user role matches node vocabulary, user can see node even if he is not in the node’s group. That’s not good.

Possible solution: Extensible Node Access : http://drupal.org/node/122173

Added: Added og_node_access() function.
Modified: og_nodeapi() and og_db_rewrite_sql() functions.

(Below are my own customizations not necessarily related to access control)

Modified: og_og_create_links($group) function to use addform (custom node creation content submission CSP page).
Modified: og_form_add_og_audience() function. This changes puts a value in gids on node edits, which causes OG Config to respect the “Audience checkbox” on content edit. That is, if “Audience checkbox” is unchecked, then NO checkbox is presented on content edit (before this modification, the checkboxes would not appear on content creation, but would appear on content edits).
Modified: og_search_form($group) to say “Search Group”. Makes it a little less confusing.

• OG Forum (required for og_user_roles)

• OG User Roles (custom module updated from 4.7: SDL)
Using this format to create documents:

http://clients.mysite.com/node/addform?type=document&gids[]=12
(where '12' = groupID)
Note: When users get “access denied” using the above url, it’s usually because the addform node (node/20) contains vocabulary that has been updated. The node itself needs to be re-saved with “public” box clicked on OR all groups checked (so all group users can use it).

Added these functions: expand_checkbox_columns($element), og_user_roles_elements() for multi column checkboxes as per: http://drupal.org/node/41936

• Taxonomy
Note: “Categories” pulldown menu of vocabulary terms is created in taxonomy_form_alter. The db_rewrite_sql is actually handled by taxonomy_access_db_rewrite_sql.

• Taxonomy Access
(allow access according to roles – this will be used for documents)
Discovered that I need to set to “Deny” (not ignore) all permissions that are NOT allowed in a role. That is, if the role can list Term 1 but not Term 2, then Term 2 must be specifically “Deny”-ed. This is discussed in TAC Help: http://clients.mysite.com/?q=admin/help/taxonomy_access
Also here: http://drupal.org/node/68883

Added: taxonomy_access_node_access() function.
Modified: taxonomy_access_nodeapi() and taxnonomy_access_db_rewrite_sql() functions.
Modified: function taxonomy_access_node_grants($user, $op) (to use user_all_roles_array($user))

• User (updated)
Modified: user_access
Added: user_all_roles($user), user_all_roles_array($user), getgid($nodeID, $uid), user_table_exists($table).

• UserNode
Don’t forget to set permissions – Give Authenticated users node: create uprofile / edit own uprofile and usernode: edit own usernode.

• Views
Modified: views_taxonomy.inc: Exposed “user_roles” and “term_access” tables to Views.
Modified: views_upload.inc: Created field to show file attachment descriptions instead of filenames.

Access Control

nodeaccess module for 5.x

fago@drupal.org — Thu, 12 Apr 2007 11:27:50 +0000

I've put some work into a 5.x nodeaccess module. It could be the superior from the current nodeaccess module, and perhaps also from the simple_access module. I'm waiting for feedback from the authors..

So my module provides extended role based access control per content type, but it can be configured to manage per user access control per node - it does this by integrating with the ACL module, as well as role based per node access control.

Like simple_access it doesn't touch any permissions when it's activated. It also does some performance optimizations and tries to keep the UI simple.

Read a more detailed description or download and test the module at http://drupal.org/node/135693.

Access Control

How to Make OG and TAC Work Together: Step 1

somebodysysop@drupal.org — Wed, 11 Apr 2007 05:11:28 +0000

As I stated in the Group Description, my goal is to figure out how to make various access control mechanisms work together. I started this by trying to make OG and Taxonomy Access Control work together: http://drupal.org/node/122712

I now intend to share with you all exactly what I did. There are a number of hacks involved that I'm sure most of you won't want to get involved with, but the idea here is to demonstrate what I did, step by step, in order to solicit ideas from others on betters ways to accomplish the goal.

Step 1:

Install the OG User Roles 5.x module: http://drupal.org/node/87679

I created this module in order to define roles that are restricted by group. This plays a major role in my access control as my site is group oriented -- that is, virtually all of it's content is organized by groups.

The module can be downloaded here: http://ftp.scbbs.com/pub/drupal/og_user_roles/

Buyer Beware: It is not an official Drupal contribution, but my own hack to accomplish the stated goal. You may want to read the background on it (http://drupal.org/node/87679) thoroughly before deciding to install.

Anyway, this is step one to getting TAC and OG working together. I'll continue with the next step shortly.

Good luck!

Access Control

my goal in joining

Ricco — Wed, 11 Apr 2007 03:35:55 +0000

Hey Folks, you got another members. Here's is why I joined. I am new to drupal, and loving it. I have an install that is using OG, and again, I am loving it. I have added a wiki content type, and have started to create some wiki pages... and am loving it :)

then one day I said, "you know, i would really like my wiki pages only to be viewable to members, and not viewable to visitors." So I started looking into TAC, and the other node access modules. And what I found was what has already been described by the founder. My private groups were now accessible to people... argh.... i must be doing something wrong... after playing around with settings for days, and going to the IRC, I came to the conclusion that OG and TAC (and other node access modules) just don't work together.

So I said... ok... this really can't be a issue that nobody else is ever gonna do... it must be common, and if it isn't common, it is gonna be, and more people use both OG and TAC... I I looked around, and found at least one other person that saw this same issue, and apparently had overcome it. I wanna hang out with him!

So here I am. Hopefully, I will learn how to make my wiki pages only available to members, and not destory the permissioning of my private groups, and in the long run will learn how, and then will be happy to document for others how this is done.

Feel free to ask me to do anything documentation, or testing wise... and... here I am.

Cheers! Ricco

Access Control

deny is possible

moshe weitzman — Thu, 29 Mar 2007 03:35:31 +0000

perhaps some people don't realize that any module can propose a DENY for a given nid. just implement hook_node_access_records() and return a 0 0 0 grant with priority = -10 and you will effectively deny access. it doesn't matter that user is a member of a group or has access to a term.

Access Control

OG User Roles

somebodysysop@drupal.org — Wed, 28 Mar 2007 08:12:28 +0000

My first step is to figure out a way to open up user_access so other modules can add roles as they deem necessary. Here is the request for assistance I posted to the Drupal Development list which describes what I'm trying to do. Any asisstance will be highly appreciated and help move this project forward:

I am proposing a new project: OG User Roles. I have written to this list before and what I discovered was that I really needed to formulate a proposal for some sort of user_access hook that would include permissions granted from other modules to the final list of permissions for a user during a particular process.

That, essentially, is the modification to user_access that I have created so that my module would work. Briefly, my OG User Roles module is designed to assign role(s) to a user restricted to the OG group he is in. Details on it are here: http://drupal.org/node/87679.

What I have found is that my modified user_access (and therefore my proposed hook) works for node listing/view/updating/deleting, but NOT creating. I am able to create nodes with the modified user_access only if I call the node_add() function directly. Not a real good solution.

So, I'm back here to ask:

What else, besides user_access, does the default node/add mechanism call for permissions checks?

Here's the scenario: I've given a user in a group a role which allows him to create a document. When his group menu comes up, he sees a "create" link to the document he's been given access to create (that means my modified user_access is working). However, when he clicks on the "create document" link, he gets "Access Denied" message.

I wrote some debug code that writes out to a file the variable values from my modified user_access function when the user clicks on the "create document" link. What I noted is that the corect permissions and group context are always returned. What happens when it fails, i.e., user receives "Access Denied", is that the function loses the arg (arg(0), arg(1), arg(2)) values. They just disappear. This never happens on successful submissions.

As you can probably see, I can't very well propose a hook if my simulated hook is not working correctly. Can someone give me some clue as to where I need to look in the node/add process to figure out why I'm losing the arg values and getting the denied error when user_access is bringing back the correct permissions?

Thanks so much.

Access Control