Group "Upcoming" and "Calendar" subnavs should be more visible

[boonebgorges]

Group calendar visibility is closely tied to group membership. 'user_can_access' is hardcoded to is_group_member. A couple problems here:

a. It's inconsistent. The top-level group nav item inherits the visibility/access settings of the group (by using the default settings in the group extension constructor). So, in a public group, you can go to the Events tab and see the Calendar content, but you can't see the Calendar subnav item. b. Related: Non-members have no way to see the Upcoming view. Seems to me that the visibility for Upcoming should generally be the same as for Calendar, since it's the same content, just in a different format. c. It's impossible to customize any of this.

I'd like to make the following suggestions:

1. "Calendar" and "Upcoming" nav items should inherit the visibility settings of the group. Public for public groups, members-only for non-public.
2. These values should be filterable/configurable. This means either (a) removing the user_has_access param when configuring these two nav items, and then passing the nav setup args through a filter, or (b) setting user_can_access to something like current_user_can( 'bpeo_view_group_events', $group_id ), so that callbacks can map caps in a custom way

Any thoughts about the above? ping @r-a-y

[r-a-y]

1. "Calendar" and "Upcoming" nav items should inherit the visibility settings of the group. Public for public groups, members-only for non-public.

Sounds good. This was probably an oversight on my end.

(b) setting user_can_access to something like current_user_can( 'bpeo_view_group_events', $group_id )

This sounds like a better idea than using a filter.

I've implemented these thoughts in commit 9ec1d72. Let me know what you think. I decided to go with the custom cap, 'read_group_events' to be similar to the existing cap names.

[boonebgorges]

This looks great! Thanks, @r-a-y !