The hooks hook_og_role_grant() and hook_og_role_revoke() have a problem: they are each invoked for each role change for a membership. This means that reacting to changed in specific roles quickly gets messy.

Suppose I want to do something such as send an email when a user is granted the 'member' role, but NOT when they are also an editor.

function mymodule_og_role_grant($entity_type, $gid, $uid, $rid) {
  if ($rid == MEMBER RID) {
    if ({user isn't also an editor}) {
      // Do something
    }
  }
}

That seems to me to have potential problems. What if the user is being granted BOTH the member and editor roles at the same time? Which order they are being granted in? If editor is granted first, then you should be okay. If member is granted first, then this function doesn't stand a chance.

I think there needs to be a hook that's invoked only once when roles are changed for a user, so that implementations can compare before and after cleanly.

However, that's going to be a easier said than done, as the whole of the API around role changes works with single changes: og_role_grant() / og_role_revoke().

Comments

amitaibu’s picture

You can always "register" the changes in a static function, and act on it via hook_exit() or similar

joachim’s picture

I might actually need to do that as a workaround. Thanks!

(I'll feel really dirty doing it though... :/)

amitaibu’s picture

Category: Feature request » Support request
Priority: Major » Normal
Status: Active » Fixed

> (I'll feel really dirty doing it though... :/)

I don't think it's any different that for example checking if 2 different nodes were saved on the same request, so you should feel only half dirty ;)
Marking fixed, unless you think differently.

joachim’s picture

In the end I found a different way of applying the business logic I need for role changes...

It would be nice not to lose this one, and change the way roles are handled in D8. There's no D8 branch yet, so maybe come up with a tag for things to consider when the time comes?

Status: Fixed » Closed (fixed)

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