Opened 7 years ago
Closed 7 years ago
#7608 closed enhancement (fixed)
Use BP_Groups_Group visibility and access properties.
Reported by: | dcavins | Owned by: | djpaul |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 2.9.0 |
Component: | Groups | Keywords: | has-patch |
Cc: | dcavins |
Description
When checking visibility for the current user, use the is_visible
property in BP_Groups_Group
rather than calculating it again. Similarly, use the user_has_access
property when checking access to a group. (is_visible
was introduced in 2.9.)
Attachments (3)
Change History (14)
#1
@
7 years ago
- Keywords commit added
If ->is_visible
handles both private and hidden groups correctly for this change, go for it.
#3
@
7 years ago
- Owner set to djpaul
- Resolution set to fixed
- Status changed from new to closed
In 11761:
#4
@
7 years ago
- Keywords commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening because the changes to bp_group_is_visible()
allows unauthenticated users to view a private group's homepage:
https://buddypress.trac.wordpress.org/browser/trunk/src/bp-templates/bp-legacy/buddypress/groups/single/home.php?marks=78#L75
@dcavins - Although it makes sense to use the 'is_visible'
property in the bp_group_is_visible()
function, we should probably revert due to backward compatibility issues. I don't have any bright ideas to fix this without introducing changes to our templates, which I don't think we want to do.
#5
@
7 years ago
@r-a-y
Thanks for your comments. I see what you mean-- the function bp_group_is_visible()
wasn't actually checking visibility, it was checking to see if the user had access. Here's a list of places in BP where we use bp_group_is_visible()
to enable access to something:
groups_action_group_feed()
: to display the feed or not (items posted to private groups are sensitive to the current user anyway, now)bp-legacy/buddypress/groups/single/cover-image-header.php
andbp-legacy/buddypress/groups/single/group-header.php
: Whether to display Admin and Moderator listsbp-legacy/buddypress/groups/single/home.php
: Whether to load thebp_groups_front_template_part()
bp-nouveau/buddypress/groups/single/parts/header-item-actions.php
: Whether to display Admin and Moderator listsbp_nouveau_group_template_part()
: Whether to display group no-access message.
Bummer. I suppose we should revert it, but can we, instead of putting the old logic back directly, have it wrap a call to bp_current_user_can( 'groups_access_group' )
, and also add a comment about how the name got out of sync with the actual property it's checking. Also, before nouveau is released into the wild, can we just replace those checks with calls to the access_group
check?
I'll attach a patch that includes the above.
Thanks again for catching this misunderstanding on my part.
#6
@
7 years ago
I like revert.02.patch
. Didn't even know of the new bp_groups_user_can_filter()
function!
I think the changes to the Nouveau templates are good, but I believe the 'group_id'
parameter needs to be passed in the bp_current_user_can()
function?
Other than that, let's roll with your patch. Thanks @dcavins!
#7
@
7 years ago
Hi @r-a-y-
Thanks again for your feedback. The group_id
is optional in those bp_current_user_can()
calls because bp_get_current_group_id()
is reliable in those two instances (and bp_groups_user_can_filter()
uses it to get the current group if no group_id
is passed). I'm leaving it off to keep it simpler (in those template uses), but we can add it to be complete if that makes more sense.
@boonebgorges, as the keeper of the history of the groups component, can you check my "historical note" in the attached patch to make sure I'm actually correct in my understanding?
Thanks!
Use BP_Groups_Group properties in some cases.