Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.point 1:
Is there any reason that OG Roles are not loaded along with an OG Membership entity when it gets loaded?
From my perspective, it doesn't make sense to have a set of OG Roles without a corresponding OG Membership, if roles are applicable, and vice versa.
In my case, I want to see all the information about a membership when i load it, and not have to load membership and roles independently using a complicated set of join keys.
og_membership_load() should attach any OG roles to the instance of the membership entity being loaded.
point 2:
OG Roles don't exist independently of OG Memberships, right?
In other words, there's no use case in which a user has OG Roles for a group that they don't belong to, right?
In order to facilitate implementation of point number 1, the og_users_roles table should include a foreign key for og_membership.
Comments
Comment #1
AaronBaumanJust a little more about the motivation for this report:
I am building an application that synchronizes group membership and roles with a third-party system.
Without a way to save roles during hook_entity_save (ie. while saving a membership object), this becomes significantly more complicated to do correctly.
If og membership user roles were attached to a membership object, and saved at the same time a membership object were saved, this problem would become trivial.
Comment #2
Yuri CreditAttribution: Yuri commentedI agree, I don't see the real logic in the current membership / role behavior. Good point.
Comment #3
japerryThere is some more discussion about this for OG roles in commons. We're having trouble with views because the needed links between the two tables don't exist.
It makes using OG role filters pretty much impossible.
http://drupal.org/node/1821808#comment-7224522
Comment #4
Leeteq CreditAttribution: Leeteq commentedComment #5
amitaibuHow is that critical?
Also discussion probably be in #1821808: Group contributors block should show group organizers first
Comment #6
j.branson CreditAttribution: j.branson commented+ this. I've just run into major hiccup. The og_users_roles need to correspond to og_membership in order to pull through content based on users roles. Also to run db_merge some incremental index would be nice. I've built a workaround on the php side as a temporary fix for my specific use case, but basically join queries don't work without either `og_membership`.`id` corresponding to `og_users_roles` or at the very least an unrelated unique id on the `og_users_roles` tables. My guess is that the easiest thing to do is patch og.install with an AUTO INCREMENT field on og_users_roles. Running drush updatedb from that should just merge right in with preexisting data without too much sweat. I don't have time to address this now, but props to anyone who does!
Comment #7
AaronBaumanComment #8
joachim CreditAttribution: joachim commented> og_membership_load() should attach any OG roles to the instance of the membership entity being loaded.
This makes a lot of sense to me.
> In order to facilitate implementation of point number 1, the og_users_roles table should include a foreign key for og_membership.
I'm less convinced of this. If OG internals take care of attaching OG role data to a membership entity, do we really care what og_membership_load() has to do in order to make that happen? It just has to run a query with a couple of extra WHERE clauses.
And if roles get loaded when you load the membership, would you ever need to get the membership from the roles? If you knew you wanted the membership, load that, and you have the roles too.
I think the only argument for this would be if it helps performance to query on a single column which could be flagged as a unique key.
Comment #9
AaronBaumanPoint taken, and agreed.