Implementation of og_access with ACL

Not interested in ACL specific code embedded in OG

hmmm, is there a better way to achieve same functionality?

You can also consider ACL integration as contrib, i.e. not inside the OG package, however:
#196922: Multiple Node Access logic patch tries to allow all the different access control modules to work together - It's not ready but maybe worth putting the energy there.

looks simple enough. please make a new contrib project for this. i am not inclined to distribute it within the og package.

@Paolo,
* You need to apply for cvs access - http://drupal.org/node/59
* You need to fix your module's coding style - http://drupal.org/coding-standards

After you'll create a project surely people how need the functionality will try it.

Paulo,

I am trying your new "module" now . . . if it works as planned, I think this is a great idea and strongly encourage you to submit as a project.

I have been wrestling with ACL/Content Access integration using OG User Roles and node.multinode patch all morning w/ no luck.

If this will achieve this functionality w/ the minimum of cruft, I think it's a great idea (at least until Drupal core has some way of combining access permissions from different modules).

-Jon

I think this is a cool resource if it works.

#196922: Multiple Node Access logic patch tries to allow all the different access control modules to work together - It's not ready but maybe worth putting the energy there.

I have been wrestling with ACL/Content Access integration using OG User Roles and node.multinode patch all morning w/ no luck.

Yes, i've wrestled for 4 days with ACL/CA/TAC/OG, it's too much complex (AND, OR mixin it's not good), and i don't like mixing the logic with the data (assign a category "NONE" to contents), with og_acl it's really simple to create "og shared resources".

Let me just point out, just to respond to the gripes, that the goal of the multinode access patch is to combine *multiple* node access sytems, not just one or two. CA/ACL integration with OG was just a by product of my original effort, which was to get TAC working with OG.

Yes, it's very complicated. But, in Drupal, so is the concept of getting multiple node access systems to respect each other. The whole point of providing "AND" and "OR" is to let the end user define the node_access logic. Of course making just ACL and OG work together is simple. Then, we end up with a module to make ACL and OG work, one to make Domain Access and OG work, one to make TAC and OG work, etc.., but still nothing to make ALL of them work together. Maybe combining multiple node access systems not a good thing in the first place. But, that's the goal.

We continue to be open to any and all positive suggestions for simplification.

For user's who are only interested in CA/ACL integration, I'm happy to refer them to this module when it's released.

Okay, I implemented the og_acl module and it seemed to work YESTERDAY.

However, now, it seems I am back to zero and cannot get og or acl permissions to work together.

Let me give example:

As admin 1, I created node and posted it to private group
Logged in as NormalUser, I tried to access node (no luck - as expected - since I did not belong to this group)
As admin 1, gave NormalUser view/update permissions for that node
Logged in as NormalUser, tried to access node (STILL no luck -- says I need to be member of this group)

I swear this was not behaving this way yesterday. Instead, NormalUser could get access to node IF it belonged to group OR was given view privileges via ACL. I have no idea what changed.

Now, I can get Drupal to respect ACL or OG access permissions by changing "priority" of ACL in Admin> Content Management > Content Type > CCK Type > Access Control > Advanced. (This allows me to change "weight" of ACL module.)

But, I cannot get them to work together.

While I love the feature set provided by OG User Roles (and/or for multiple modules) . . . I just don't need the extra functionality it provides and could not get it working quickly. (Deadline is tomorrow.)

I had high hopes for this "module" but now cannnot get it working. (Feeling dumb ... I don't know what I am doing wrong.)

Okay, so I have figured out that the acl "per node" settings do work IF you set them in the Access Control TAB on the node.

However, if you use the ACL fieldset available under the Edit tab, it does not work.

Using the example above, let me go into detail:

USING ACL Section under "Edit" tab -->

As admin 1, I created node and posted it to private group
Logged in as NormalUser, I tried to access node (no luck - as expected - since I did not belong to this group)
As admin 1, gave NormalUser view/update permissions for that node USING THE ACL section under the Edit Tab
Logged in as NormalUser, tried to access node (STILL no luck -- says I need to be member of this group)

USING Access Control "tab" for Node -->

As admin 1, I created node and posted it to private group
Logged in as NormalUser, I tried to access node (no luck - as expected - since I did not belong to this group)
As admin 1, gave NormalUser view/update permissions for that node USING THE "Access Control" tab on node ("grant own access" must be enable under Admin > User Management > Access Control)
Logged in as NormalUser, tried to access node (EUREKA! -- problem is: how does the user know to use the AC tab and not the Edit tab ... it's confusing!)

Next step(s) for me:

See what's going on in the database tables

If no luck, try OG User Roles Integration AGAIN!

Okay, have no idea if this is helpful, but just posting the results of my investigation(s) . . .

It seems that the information entered into Access Control Tab and information entered into ACL fieldset under Edit tab both get their own ACL ID in ACL_node table:

acl_id nid grant_view grant_update grant_delete

37 230 1 0 0 --> entered using fieldset under "edit" tab

49 230 1 0 0 --> entered using Access Control tab

This gets entered as follow in ACL_user table:

acl_id uid

37 16

49 16

Meanwhile, the ACL table itself shows:

acl_id module name

37 og_acl view_230

49 content_access view_230

I am guess this indicates that for acl id #37 og_acl is activated or used for access, while "content acces" is used for #49.

W/out knowing more about how these modules work, I cannot even guess why this is - or what it means - but I am just reporting what I know right now.

Okay, so this has been a real learning process for me.

Now, I understand that:

1.) The OG_ACL module was what was adding the ACL fieldset under the "edit" tab
2.) ACL alone does nothing to UI (Thought I understood this, but evidently not)

However, I still cannot get Drupal to respect permissions set using OG_ACL.

Fortunately (and weirdly enough), I think CA does . . .

What finally worked for me was just enabling (w/out OG_ACL) and then setting the default user role permissions for CA for all content types to "none." (This way they do not interfere w/ OG.)

Then, I granted "grant_own_content_access" to my users.

This way, individual authors can override OG permissions on a "per node" basis, but they cannot do anything else.

So far, it seems to be working fine, w/out og_acl.

I am still confused about some things (like why this did not work before), but am pretty happy w/ the results for now.

Well, I sure hope I am right and the current config does what I want . . . as long as Content Access rights always ARE "OR"d w/ OG rights, I feel like I am fine.

As long as Content Access cannot take away permissions already granted by OG (placing post in specific group, or marking as public), I am good.

I just need to make sure CA can ADD rights, w/out interfering w/ rights already granted by OG.

(It seems to do that for now, but it's awful hard to test.)

-Jon

Hi all,

Is there any news on this? Has a module benn released?

Thanks,
Pascal

Hi all,

Is there any news on this? Has a module benn released?

Thanks,
Pascal

any news of a contrib module with Paolo's functionality in the meantime?