og_get_group_context() doesn't find a group

Hmm, that's odd, I have this deployed on a client's site and it's been working great! Can you explain a little more about how you are using this module?

You are correct though, that og_get_group_context() must be able to find a value in order to be able to grant access. There should be something in the documentation about how that function works and when it will be able to find a group context, since it doesn't check arguments.

Generally, og_get_group_context() will get defined when you are looking at a node that belongs to a group (and have permissions to view that node), or a group node itself. The access plugin will then use that group to check access against.

(edited to add more detail about og_get_group_context())

Nope, I didn't have to mess with the weights at all.

Perhaps a print_r() to check what og_get_group_context() is finding will shed more light on why it's not working as expected? What behavior are you seeing vs what you think should happen?

I'm finding that the module is not working at all for me (tried setting 'member/member||admin/not a member' and the view is not visible to anyone, except User 1), so group members are still unable to view relevant Views.
However, I use og_get_group_context in the following PHP snippet to control an OG navigation block visibility - so it appears on every group node where the user is a member of that group

<?php
//first check if OG installed
if (module_exists('og')){
    if (($group = og_get_group_context()) && node_access('view', $group)) return TRUE;
}
?>

Is this any help, or am I barking up the wrong tree?

Hmm, this is getting more serious, I will make an attempt at some more in-depth troubleshooting. We're going to need some reproduce-able test cases, do one of you two mind posting an export of a view that's not working? Also, the details of how you have OG configured might be useful, since there's a lot of variability there. Or if you have a demo site w/o sensitive information on it, that could work.

@snorkers:
When OG sets the group context during og_init() it already checks for node_access('view', $group) at the bottom of og_determine_context_get_group(), so that should be about the same.

This may be significant though: I don't have the optional og_access module installed, since I'm not using the public/private group concept. Do either of you use it, and if so, how is it configured?

Thanks for more detail!

@kscheirer yes I do use the OG access settings. Currently I have the following set:

- Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to public.
- Group administrator chooses whether her group homepage and audience are private or not. Defaults to public.

I am building a combined public website and enterprise intranet type site - so each OG has a mix of public/private content, although most Group home pages are public. I've just realised a crucial flaw in my site: all the group admin 'dashboards' are built on Views - and no Group members can currently access these Views (poor testing on my part). The Access restrictions > Role should have worked (ie, without use of this module), as all group members are automatically assigned a Drupal Role of 'Group Member' (using OG User Roles); but it wasn't working... so coming across your module seemed like a blessing.

My first test was to set the [OG dashboard] Views to Access restrictions none. In that View I also inserted a PHP snippet in the View header to print out the Group ID (from og_get_group_context) and whether current user is a member of that group using og_is_group_member. Then I accessed the View as a group member - my PHP snippet showed correct group ID and that current user was a member. However, as soon as I change Access restrictions to any OG Views Extra setting, the View generates a 403 error.

So I'll keep working away at this, but I think there's also a chance that there's nothing wrong with the logic in the module, and the problem could lie elsewhere in OG, possibly OG User Roles...?

@marcp I just tried your patch and works fine. The Views > Arguments validation seems to work pretty well and may be the better way to validate Group members/admins.

Still no further in getting OG Views Extra to work for me :(

I am not able to set the permissions right. the view and its tab menu or any menu is accessible by non members and even anon users. This module is a good one if works properly.

I updated the module description and README.txt file to make it clear that this module doesn't work with Views arguments, hopefully that should reduce the confusion.

However, I see your patches to OG have been going well - is there any use for this module at all anymore?

IMO, the patches to OG offer the exact same functionality that this does, so that this module duplicates functionality that is already in OG.