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.
The way that OG handles roles is different in the 2.x branch of OG.
1. The function og_get_global_roles() has been replaced by:
og_roles($group_type, $bundle, $gid = 0, $force_group = FALSE, $include_all = TRUE)
2. og_get_group() is also deprecated. See this issue: #1670642: og_get_group replacement
Until this module fully supports OG 7.x-2.x, I recommend making a warning on the project page stating as much.
Comments
Comment #1
greg.1.anderson CreditAttribution: greg.1.anderson commentedThanks for the notification and pointers. I have put a note on the project page, and will get an updated release supporting og-7.x-2.x out as soon as I can.
Comment #2
carsonblack CreditAttribution: carsonblack commentedAttached is my first pass at patching this.
Some notes:
1) line 275 in og_role_watchdog.pages.inc: Added greater than 0 as I had some cases where the rid was coming through as zero. Not sure if that's a problem with the input side of storing the data or if that is a valid role id when a brand new person is added to a group without a role?
2) I have put in some @todo before the calls to og_is_group_default_access() functions because I'm not sure if these are necessary in the places that they are being used. The reason why is because I am thinking that if the default access thing is set it would effect the output of roles when you call og_roles. Not sure if that is correct so maybe someone else can chime in on that one.
Comment #3
carsonblack CreditAttribution: carsonblack commentedAttached is patch with the paths set correctly so the patch will actually apply if you stick it in the root directory of the module! ;-)
Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere is something I started, but put aside; this version attempts to support both the 1.x and 2.x branches of og at the same time. It is unfinished and untested, but I think it is pretty close. One of the main thing it needs is an update hook to look up and store the group type in the Og Role Watchdog table; however, I think it might be better to just back out the addition of that field, and look up the group type every time. I'm not sure.
Comment #5
Shawn DeArmond CreditAttribution: Shawn DeArmond commentedThis brings up an interesting point. Does it makes sense at this stage to break out og_role_watchdog into a separate module so it can have a 7.x-1.x and a 7.x-2.x branch mapping to OG 7.x-1.x and 7.x-2.x?
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedIt seems that it would be possible to support both versions -- but only if I back out that code that adds a different field to the og_role_watchdog table. If I need to modify the orw table schema, then I'd better have 7.x-1.x and 7.x-2.x versions for orw. Otherwise, there won't be any way to know when to run the update hook to adjust the schema; if you updated orw first, and og later, you'd be sunk.
I guess I'd better split it out into a separate module, just to be safe.
Comment #7
MMachnik CreditAttribution: MMachnik commentedWe're taking a look at this to try to get it working with OG 2.x -- has anyone done anything with this? Thanks! :)
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedSo much time has passed... I am currently running role_watchdog with og 2.x, but I don't remember which branch of the code I forked from. I guess I never really decided what to do about the og 1.x vs og 2.x support, which is why I never came back and updated the patch here.
I'll diff my code against the current release, and put it up here.
Comment #9
greg.1.anderson CreditAttribution: greg.1.anderson commentedJust did a review of what I have installed, and it looks like I just turned off role watchdog.
I think that the suggestion in #5 is best here; og_role_watchdog should become its own project, so that it can have a 7.x-1.x and a 7.x-2.x version, to support og 1.x and 2.x, respectively.
Failing that, I think we could also just abandon support for og 1.x, and keep og_role_watchdog here. This is the easier option, if og 1.x is not needed by anyone. I don't need it, at this point.
Help is appreciated here.
Comment #10
Chris Burge CreditAttribution: Chris Burge commentedAttached is a modified version of patch #3. It corrects an issue where _og_role_watchdog_remove_role() doesn't check if the membership type is 'user'. Without this fix, the function executes on all entities (nodes, files, etc.), which causes errors as the code assumes it's dealing with user entities.
Comment #12
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs for DrupalFit commentedPushing this much would be fine for now. Will be working on it closely in upcoming to check for more possible integrations with OG.
Comment #13
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs for DrupalFit commented