I you have a lot of groups in your system and you have a user that is a member of large number of groups, the performance of any action because very slow as a result of all the entries in the node_access table. Now, that said, I don't see where these entries are needed. The only thing they are doing , that I can see, is helping users view unpublished nodes. The thing is, og will take care of that for us as long as og_moderation provides the permissions management. So I propose we get rid of:

function og_moderation_node_access_records($node) and
function og_moderation_node_grants($account, $op)

When I have done this my users members can still view unpublished content, yet non members get access denied. I feel like I must be missing something but can't figure out what it could be. In any case, patch to follow with the change I am suggesting.


Status:Active» Needs review
new1.51 KB

Attached is patch that removes the two functions that, I believe, are not needed and cause performance issues.

Status:Needs review» Active

I realize now that OG doesn't handle the cases where it's not a full node view. The patch above would make it so that views and other aggregate lists will not show the items for group members. Need to figure out way to get performance manageable with such large table or come up with different approach.

Status:Active» Needs review
new2.08 KB

With this approach, we only add grants when in a group context and only add the grant for that group context. All the time is not spent accessing the table but in generating the grants for each and every group/type and each operation. The down side of this approach is that it's dependent on og_context. I think this is ok because if we don't have a group context do we really want to apply og_permissions?

Title:node_access table becomes too big when users are members of a lot of groupsNode access too slow when current user is member of large number of groups.

Status:Needs review» Fixed

Committed to 7.x-2.x branch.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.