I'm trying to figure out how I can allow members of a group to flag content in the group. They shouldn't be able to flag content in other groups, but I'm having trouble figuring out how to configure my Flag settings and the Group permissions in order to achieve that.

I have a Group and then another content type, call it Group Page that will have flagging. At first I setup a flag, call it "Featured" with none of the "Roles that may use this flag" checked, and then went to the OG Permissions page and allowed all members of the group to "Flag Node entities as Features" and the unflag group permission as well. When that didn't work I updated my "Featured" flag so that all authenticated users could use the flag.

Looking at the code, I think that is the way it is intended to work (looking at OgFlagNode::user_access):

  1. Create a flag and grant all roles that should be able to use the flag
  2. In OG Permissions restrict which member roles to grant access, making access less permissive

Even when I configure it that way it seems that a user can use the flag even in groups that they aren't a member of.

Comments

gildir’s picture

I believe it should actually work this way:

  1. Create a flag and grant access to roles who should have access regardless of their group membership (for example, admin)
  2. In OG Permissions select which member roles to grant access to, making access more permissive

This is more standard, with additional privileges being granted, not missing privileges being restricted.

That said, this set up also does not seem to work since only group-specific overrides appear to be being checked. Attached is a patch which adjusts to work at above. This also requires:

  if (module_exists('og_flag')) {
    foreach ($filtered_flags as $flag) {
      if (method_exists($flag, 'setContext')) {
        $flag->setContext();
      }
    }
  }

be above:

  // Filter out flags based on account permissions.
  if (isset($account) && $account->uid != 1) {
    foreach ($filtered_flags as $name => $flag) {
      // We test against the 'flag' action, which is the minimum permission to
      // use a flag.
      if (!$flag->user_access('flag', $account)) {
        unset($filtered_flags[$name]);
      }
    }
  }

in function flag_get_flags() in the flag module, so I'm also uploading a modification of the patch that comes with og_flag for the flag module.

gildir’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 1: general-group-permissions-flag-patch-2205269-1.patch, failed testing.

gildir’s picture

Status: Needs work » Needs review
StatusFileSize
new554 bytes
jojonaloha’s picture

Category: Support request » Bug report
Status: Needs review » Reviewed & tested by the community

Just tested this against Flag 7.x-3.5 and OG Flag 7.x-3.0-alpha1 and it seems to work great!

nchase’s picture

I can't get this to work.

With Flag 7.x-3.6 and OG Flag 7.x-3.0-beta1 I have set up a flag on a node. With OG Flag I configured the group to only allow members to flag content. It doesn't depend if I'm a group member or not: the flag shows up. It doesn't depend if I the flag is on the group itself or on group content: the flag shows up.

When I remove access for a role at the flag itself the flag vanishes for the role - even if allowed by the group settings.

I followd the steps at the README.txt - applied the patch -> No luck.

nchase’s picture

Just to clarify: the override of settings works fine. I can for example rename the link of the flag on a group basis. What isn't working are the permissions.

howards’s picture

I played with this about two months ago and had things working, though I will watch for the issues noted by Nchase when I use it in a new project. In the mean time, I've rerolled the flag patch against 7.x-3.6 and 7.x-3.x-dev (specific revision because of makefile) to clean the patch application and avoid huge hunk offsets and eventual failure.

The files are hidden because I'm that insecure. :)

EDIT: AH, $#!+ ... I placed the code for those two patches in the wrong spot ... SOB. Don't use the patches attached to this comment, they don't appropriately use the $filtered_flags variable .. FU..dge.

EDIT 2: Now we know why I hid those files to start. :( Now I know the actual reroll process; self incompetence is frustrating.

howards’s picture

Here's an actual reroll ... I'm so dumb. Again, hiding ... but much more confident this time... :/

howards’s picture

StatusFileSize
new670 bytes

@Nchase I remember there being something about the original patch that didn't seem to jive with permissions. I looked back at a previous project that utilized this and noticed I'd written my own patch (based on the original posted here for og_flag), but it looked like something was off to me. It looked like the permissions were reset based on whether the flag was *also* overridden.

While I'm not completely sure, it looks like the original patch looks at whether there is site-role access to the flag and there is an og_context. [if (!$access && $this->ogContext) {] If there is no access to the flag based on the site's roles, but there is ogContext, then it grants access. Then the code looks at if site-wide access is granted, and there are overrides applied, [if ($access && $this->overridesApplied) {] then it readjusts permissions and may completely forget about the first if() conditional.

I created a patch for my own personal use on the other site that seemed to work. It simplifies the "readjustment" part of the code and combines the two if() conditionals into a single statement and then sets the permissions accordingly.

Try this patch (as opposed to the original), and see if it fixes your issue(s). (I hope I'm not too late with this...)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 10: general-group-permissions-2205269-10.patch, failed testing.

howards’s picture

StatusFileSize
new660 bytes

Geez, I can't do anything right! I'm sorry for all the noise I'm creating, hopefully it results in an appropriate fix. If this doesn't work, I'm out of the game; sheesh!

howards’s picture

Status: Needs work » Needs review