Compatibility with OG 7.x-2.x

Is there??

Is it not compatible then? I don't get any errors.

As I know, 2.x branch got rid of "gid". There is only "nid" parameter left. So "comment_og.module" file needs many fixes.
Still doubt...

I'm not seeing any errors, but I'm also not seeing permissions change while using OG-7.x-2.0-beta3

I'll try this on a clean install, but what I'm seeing more specifically:
On my test version of our production site at the moment, enabling the module exposes the additional permissions as expected, but checking or un-checking any of the permission check-boxes doesn't seem to actually impact the what user can or cannot do.

og_context() changed. Here's a patch for OG 7.x-2.x compatibility.

Thank you so much, I really needed this! And a few other people too it seems.

Some things aren't quite working as expected, such as the 'reply to comment' and 'approve' buttons. Also using the '/' delimiter in the implode is adding trailing slashes for the last 2 arguments - (but this is not really a problem). I'd suggest making the following changes to the patch (I hope these are clear):

- 'href' => implode('/', array('comment', $comment->cid, 'delete', $context['group_type'], $context['gid'])),
+ 'href' => implode('', array('comment/', $comment->cid . '/', 'delete', $context['group_type'], $context['gid'])),

- 'href' => implode('/', array('comment', $comment->cid, 'edit', $context['group_type'], $context['gid'])),
+ 'href' => implode('', array('comment/', $comment->cid . '/', 'edit', $context['group_type'], $context['gid'])),

- 'href' => implode('/', array('comment/reply/' . $comment->nid . '/$comment->cid', $context['group_type'], $context['gid'])),
+ 'href' => implode('', array('comment/reply/' . $comment->nid . '/' . $comment->cid, $context['group_type'], $context['gid'])),

- 'href' => implode('/', array('comment', $comment->cid, 'approve', $context['group_type'], $context['gid'])),
+ 'href' => implode('', array('comment/', $comment->cid . '/', 'approve', $context['group_type'], $context['gid'])),

- 'query' => array('token' => drupal_get_token(implode('/', array('comment', $comment->cid, 'approve', $context['group_type'], $context['gid'])))),
+ 'query' => array('token' => drupal_get_token(implode('', array('comment/', $comment->cid.'/', 'approve', $context['group_type'], $context['gid'])))),

Thanks again for your work on this. I'll keep testing and let you know if I encounter anything else.

The URL must be like this:
comment/reply/1/2/workgroup/3
It was OK for the approve link, but there was indeed a mistake for the reply link. Here's a right patch, sorry.

Thanks for the updated patch GaëlG.

A few mix ups in my original post, as I was looking at a content type that was NOT a group-content-type - must have clicked on the wrong tab in my browser. The problem with the trailing slashes, seems to arise when looking at non-group-content types as there is no group_type/gid arguments to put in the link.

I'm still having problems with the inline approval for all content types. It resolves itself when I disable Comment_OG (C_OG) so its not a problem caused by another module (though it's possible there might be conflict somewhere). I'm getting an access denied when I click the 'approve' link even when logged in as Admin/User1. And I've enabled all the relevant OGpermissions too. I did notice that the token generated for a specific comment is different when CommentOG is enabled (approve not working) than the token generated when CommentOG is disabled (approve working) - but when I copy/paste the working token into the url generated by CommentOG (and replace the token it generated) the approve works correctly - (Hope you can understand what I'm trying to describe here!). Here's an example:

C_OG Off - Approve link: comment/59/approve&token=bGTxx01b3-yeccSAPXd3-2xXbMkIaY1r7pjDxBbxhf8 (WORKS!)
C_OG On - Approve link: comment/59/approve/node/100&token=_jbXUmxGkPLoi0OOlwahK9RLkKAqDppYaTwktKMh9y8 (Nope!)
C_OG On - Approve link: comment/59/approve/node/100&token=bGTxx01b3-yeccSAPXd3-2xXbMkIaY1r7pjDxBbxhf8 (WORKS!)

Could the problem I'm experiencing be because of the tokens being generated by CommentOG? Sorry, I know almost nothing about tokens (even less than my fairly basic php!)

I've only ever used OG7x.2x so not sure if the problem exists with OG_7x.1x and Comment_OG_7x.1x. - I'll do a fresh install and test the older versions at the weekend.

Just to clarify here's how the approve link looks now: http://mysite.com/?q=comment/56/approve/node/100&token=GxXKqL1zpTCO24eqS... and I've applied the patch to the 7x.1.0 release version not the dev7x.1x (which is older for some reason). Should I have applied it to the Dev?

Of course this might only be a problem on my system. Maybe a Dev7x.2x could be set up incorporating your patch? I know it's not been thoroughly tested yet, but a dev has to start somewhere and this would seem to be a good starting point for the new branch. Just my 2 cents on that.

Thanks again for your work and for getting back with the new patch so quickly.

The patch works for my needs. I don't have tokens at the end of my links, they look like this:
http://mysite.com/comment/4/delete/node/11
Actually I don't use approve links and comments on non-group nodes. All I did is adapt the code for og_context() changes. The module logic shouldn't have changed. The bugs you mention might not be related to the patch. Anyway, you may try to figure out what's wrong by using dpm().

How can I apply this patch?

I just wanted to chip in and say that the patch in comment 7 works well in our use case. Thanks very much GaëlG!

I wonder if one of the maintainers (chromix, rapsli) of this module confirm whether this will see an official release.

To apply the patch, try looking at http://drupal.org/patch/apply

I finally got it to apply with patch -p1 < name-of-file.

Of course, the file had been previously downloaded into the directory/folder for comment_og.

I also am having the same "Access denied" for approving comments inline (on the group page/node).

Also, I don't have tokens for delete, edit, - but they are there for approve.

Hi, would anyone be willing to send me a copy of the file with the patch? I've been trying to figure out how to do this in Eclipse for about half the day without luck :(

@lanchris: There is plenty of documentation on how to apply a patch. Anyway, you can do it manually by copy-pasting. Look at it in a text editor:
- means this line has to be removed.
+ means this line has to be added.
Other lines indicate where this has to be done (which file, which line, which function,...).

When applying patches manually, start from the bottom up. This way line numbers are nearly correct.

Thanks - I think it worked.

Do you know if there is a way to change anything so that when an OG Group member "Edits" the comment, the comment owner does not change?

OG GROUP PERMISSIONS
"Edit any comment on Food Donation Posting content
Member can edit any comment, including those posted by others. Edited comments are then owned by the editing member."

Hello i have applied the patch in #7 against 7.x-1.0 (OG 7.2) but non group members are still able to post comments...ah wait a second...... it works as hoped when i disable Panels. Obviously with Panels the comment form is always shown as thats what ive asked to happen. Let me get back to you.

Actually in effect i shouldnt really need this module if im using Panels should i? Panels lets you only show the comment form for group members. well it should , but its not. Ill take it up with Panels folks when i get back up. As ever ive ran myself into the ground trying to do the simplest of things.

Patch #7 works for me, really thank you

I went ahead and fixed this up a bit more, responding to comments in #6 and #8. The bug in #8 should probably be a bug unto itself since it probably effects 1.x integration as well.

One way or another, once I get a few people on board with this patch, I'll up the version to 7.2 to reflect the compatibility with OG7.2.

Switching to "needs review" to get some road testing.

I just tested this patch and it works just fine. I will report if I have problems with it in the next couple of days. If I did not report any issues in the next few days, it means this patch is functioning well.

Thanks for the patch.

OK, I take it back. The patch has some errors. I have a private group with private content. When a non-member views a content, he cannot see the body of the node but is still able to see the comments. I went to the permissions page and unchecked everything for non-member but it still not working. non-members should not be able to see comments. I wonder why there is no "view comment" permission as in all other fields.

I also wish for a new official release . .

thanks

@Moh - I have the same issue, although am not sure if it was in the original functionality of this module:

Non-members can view Comments attached to an Organic-Group-node to which they don't have access.

Is there a way of hiding the comments to non-members?

Thanks

I am having trouble reproducing the bug from #24 and #25. That is to say, everything seems to be working fine for me. Non-group members are denied access to private groups, and any comments attached to those groups. Non-group members are denied access to all of a group's private content and all comments attached to that content. I'm using the patch from #21 applied to the 7.x-1.0-beta+2-dev version of the module.

Do you have any tips on how to reproduce the errors you encountered?

Could you have accidentally created public content that belonged to a private group?

I'm using OG Comments 7.x.1-0 and the patch above...and it now seems to be working. I'm not sure why the issue persisted previously - perhaps a cache clearing issue...

I'm happy for this to be marked as fixed, and may (re)open if the problem arises again. (I will leave the maintainer to change to Fixed as there are others in this feed who may have a continuing issue)

Thanks

Not if the OG and OG content are set to private...

I tried this patch out on our dev server and it works beautifully for post, edit, and delete, but doesn't seem to want to work for approve (which, naturally, is what I really want it for :) ). The pending comment doesn't appear to a member with a role that allows approval, so there's no way for them to approve it. Once it's approved by somebody else (someone with the site-wide "Administer comments and comment settings"), they can see and use the other administrative buttons.

Nothing special about the page the comments are on itself; it's public to the world, as are the comments.

I don't think this is the same as #8, since they're at least seeing the button? Correct?

Using OG 7.x-2.2 and the latest version of Comment OG + patch.

So from the sound of it the problem is the approve button not showing up for the right people, not that the link isn't working. I'll take a look and let you know what I find.

I was able to get the comments to show by looking at a hook implementation in the commentaccess module and stripping it down to its bare bones.

function comment_og_query_comment_filter_alter(QueryAlterableInterface $query) {
  
  $node = $query->getMetaData('node');
  $context = og_context();
  $conditions =& $query->conditions();
  
  if (og_user_access($context['group_type'], $context['gid'], 'approve comment_node_' . $node->type) || user_access('administer comments'))
  {
	  foreach ($conditions as $key => &$condition) 
	  {
	      if ($condition['field'] == 'c.status' && $condition['value'] == COMMENT_PUBLISHED) 
	      {
		unset($conditions[$key]);
	      }
	  }
  }
}

Only thing is, I'm not going to claim to be a Drupal module expert, so I don't know if I'm doing anything completely wrong here.

@uzuri - I was unable to get that hook working. comment_og_query_alter was hooking into the bootstrap but I couldn't get comment_og_query_comment_filter_alter going. Is there a dependency that I'm missing? I have comments and comment_og enabled.

@chromix - #21 worked well for me, but in the case where:

• Drupal permissions are set to grant a user to have access to view, post, skip approval, edit comments.
• OG permissions are set to prevent a user to post, edit, delete comments on a group post.
• A Group post does not have any comments.

The comments section is still getting rendered for that user:

<div id="comments" class="comment-wrapper">
  
  
  </div>

Hope this data is helpful. Thanks for your work on this!

Sorry for the late response -- I don't believe so. All I'm running that should be even remotely related is comment_og, og, and comments.

I'm going to have to look back into this; I got pulled away, and now I don't really remember what I was doing. Let you know if I discover anything.

og_context() changed again, causing:
Notice: Undefined index: group_type in comment_og_comment_view_alter()
and
Notice: Undefined index: gid in comment_og_comment_view_alter()

I suspect changing isset() to !empty() will fix it.
Hopefully I'll get some time to investigate and create a new patch.

edit: I created #2065025: og_context returns empty array when no context is found in the OG issue queue

Attached slightly modified path that should work with all OG-2.x versions.

Sometimes d.o. fails to take files..

Seems fine to me

is there any way to get working ?

i have installed the module , applyed the latest patch , grant perms , but there is no comment form with nodes.

Wow works for me … days and days searching … Thanx :)

Patch 37 work also form me.
thanks

I confirmed that the patch in #37 works great !
I had to add the hook of uzuri #32 to get the approve link for members with Comments approve permissions.

But I still didn't figured it out how to give the permissions "Skip comments approval" to an OG role, to give members the possibility to create comments directly approved.

Can anyone confirm if this is still working with the latest version of OG? I've tried the patch, but I still don't see any effect on whether or not a comment form is displayed on group content.

ETA: nm, this was because I was using panels.

I'm using Panels and a current version of OG and this works fine.

I want to allow users with the administrator role to edit comments on a specific content type (not the drupal administrator role, just administrators of an Organic Group).
I have a view that lists comments for this content type, and I've added a "Comment: Edit Link" field.
Without comment_og, the edit link only shows up on the current user's own comments.

So, I installed comment_og, and checked the permission to "Edit any comment on Content Type content" in the "Administrator member" column.
Unfortunately it didn't do anything. The edit link was still only displayed for the user's own comments.

Then, I applied the patch in #37, and cleared the cache, but it still didn't do anything. The edit link does not show up when logged in as a user with the "Administrator" role (Administrator of the Organic Group), except for the user's own comments...

What am I missing? (I'm using Organic Groups 7.x-2.7)

EDIT: The administrator actually has the right to edit the comments, it's just that the edit link is not displayed, but apparently comment_og doesn't change the visibility of the "Comment: Edit Link" in custom views.
So, I used a "Global: PHP" field with a condition that checks if the edit link should be displayed, instead of using a "Comment: Edit Link" field.

The new links from the alter were not working for me, so I cloned the menu items and set these directly.

i.e. comment/#cid/edit/node/#nid produced a 404

As super admin, I got a normal link without the "/node/#nid" added and this passed the initial round of UAT of the module >_<

/**
 * Implements hook_menu().
 */
function comment_og_menu() {
  $comment_items = comment_menu();
  $items['comment/%comment/edit/%/%'] = $comment_items['comment/%comment/edit'];
  $items['comment/%comment/edit/%/%']['access callback'] = 'comment_og_access';
  $items['comment/%comment/edit/%/%']['access arguments'] = array('edit', 1, 3, 4);

  $items['comment/%comment/approve/%/%'] = $comment_items['comment/%/approve'];
  $items['comment/%comment/approve/%/%']['access callback'] = 'comment_og_access';
  $items['comment/%comment/approve/%/%']['access arguments'] = array('approve', 1, 3, 4);

  $items['comment/%comment/delete/%/%'] = $comment_items['comment/%/delete'];
  $items['comment/%comment/delete/%/%']['access callback'] = 'comment_og_access';
  $items['comment/%comment/delete/%/%']['access arguments'] = array('delete', 1, 3, 4);

  return $items;
}

/**
 * Implements hook_menu_alter().
 */
function comment_og_menu_alter(&$items) {
  $items['comment/%comment/edit']['access callback'] = 'comment_og_access';
  $items['comment/%comment/edit']['access arguments'] = array('edit', 1);

  $items['comment/%/approve']['access callback'] = 'comment_og_access';
  $items['comment/%/approve']['access arguments'] = array('approve', 1);

  $items['comment/%/delete']['access callback'] = 'comment_og_access';
  $items['comment/%/delete']['access arguments'] = array('delete', 1);
}

Question: Is anyone using this with multiple groups selected in the Group Audience for group content?

i applied the patch from #37 and works great for me as long as the group content is only attached to one Group. i'm only using the ability to comment or not. the default for the group type is that only group members can comment. if i select one group, then yes, only members of that group are able to comment. perfect. but, if i select multiple groups in the og_group_ref then only members of one of those groups will be able to comment. if i first select one group and save, and then edit to select more groups and save, the members from the first group will be the ones who can comment. if i select multiple groups when first creating the content, there will still be just one set of group members that can comment but i have no control over which one. i suppose there's some order to which it gets added to the database, but i haven't looked into to see which one.

so, i'd like to be able to share a piece of content with multiple groups where all the members from those select groups are able to comment, but no other users. if someone else is successfully doing that, i'd like to know how. if not, then additional groups are not getting included in the validation process. it's probably an easy fix if you understand the code, but i don't. any takers?

@insomnialex
RE: multiple group audiences
The code uses the og_context() function (like most modules integrating with OG). OG Context only returns 1 group. By design.
So thats the reason you have that issue.
It's not an easy fix, maybe you should consider a custom solution that allows multiple audiences.

patch #37 works for me, thank you!

Module author could inserted it into the module .

Igor

@rv0
RE: using multiple audience fields

thanks for your quick response and explaining the limitation there. took me a bit to do some tests.
i have tried istead setting up a second Group Audience field, where each is limited to one selection. this almost works, but has a glitch. illustrating:

Member-A belongs to Group-A and Group-B and posts a piece of content, where Group-A is in one audience field and Group-B in the other. Member-B just belongs to Group-B. Member-B is now able to comment on that content... UNLESS Member-B clicks on Group-A’s page. now, when Member-B clicks back on the content, he is no longer able to comment. the lack of permission to comment on Group-A’s content has taken over. to regain permission, Member-B must either click back on Group-B and then the content, or log out and back in. either method will restore permissions.

what is happening that changes the permission by landing on Group-A’s page, since the permissions WERE available due to membership to Group-B, even if no group page had been visited before (like simply landing on the content from a view of all nodes of that content type, after a fresh log-in)?

@insomnialex
Setting up a 2nd field is not a solution for you problem, there can only be 1 context.
It simply isn't possible with this module/patch, and the problem is more of an "og" thing as there's no standardized way of getting all the active group contexts afaik.

I tried patch #37 and some functionality didn't work.

'Delete comments' and 'Edit comments' work as intended.

But 'Post comments' and 'Approve comments' are not working.
If a comment is not approved, it never shows up on the comments list. so it can not be approved by the member.

If post comments is set to the member role by permissions, it always displays and let the user post a comment even when the option is overridden by the og comments. Same for the preview, or direct access to the comment form.

Please review the following patch.
Changes:
Multiple group audiences

• Context has been removed, and instead nid is being used to get the list of all the groups that the node is assigned to.
  This change resolves @insomnialex question about multiple groups for the same group content. https://www.drupal.org/node/1833006#comment-10361695

Post Comments

• Compatibility w/Panels
• Verify access if someone wants to post a comment using a direct link, this validation is possible because the use of nid instead of context.
• Comment access is working for comment preview as well.
• Hide/Display 'reply' link and verify access when posting.

Aprove Comments

• Verify access to approve comments, if access to approve is set using og_comment it would be available even when the user-role permissions don't have the approve comment permission set.

Delete Comments

• Working as before, similar to the post comment option the delete comment option now is using nid instead of context

Edit Any Comments & Edit Own Comments

• Working as before, similar to the post comment option the edit comment option now is using nid instead of context

Two more changes:

1. If 'Post comments' main permission is not set then remove the the 'reply' or 'edit' links. 'Post comments' permission by role is the main permission, if it this is not turned on then the comment form won't display. So it doesn't make sense to leave the 'reply' or 'edit' links as it would show an access denied message.
2. Display the comment form if the user has the 'Administer comments and comment settings' permission.

I could not apply the patch in #55 (I tried on dev and released version)

patch -p1 < compatibility_with_og-1833006-55.patch 
patching file comment_og.module
Hunk #2 FAILED at 74.
Hunk #3 FAILED at 96.
Hunk #4 FAILED at 151.
Hunk #5 FAILED at 160.
Hunk #6 FAILED at 170.
Hunk #7 FAILED at 186.
Hunk #8 succeeded at 234 (offset -1 lines).
6 out of 8 hunks FAILED -- saving rejects to file comment_og.module.rej

I could apply patch in #36, but the comment form is not shown.

@gunwald Please try this new patch -- I was working in a mixed version. But I created a new patch base on dev version.
Please try it, and once that you tested please change the status to tested by the community.
Thanks!

Note: the main permissions are the role permissions, so make sure that the user role has permission to post.

I've just tried patch #57 and seems not to be working

Hi @edutrul,

When you said it seems not to be working... what does it mean?
Did the patch fail when you tried to be apply it? Are you trying to apply the patch to 7.x-1.x-dev version?
or was the patch applied correctly but there is an issue w/functionality?

Sorry. Posted in the wrong issue :(

I tried patch #57 in a fresh install of drupal 7.41 with OG 7.x-2.7 and latest Comment OG 7.x-1.x-dev. I did not enabled 'Organic groups access control'.
Patch was applied without error.

At admin/config/group/permissions/node/#group, i configured group and content of the group so that only member can post and 'edit own'. Then i tested with various users.

At this time i only detected one problem: the permissions for the group don't seem to be working. The normal drupal permissions at admin/people/permissions are the ones that have priority.
On the other hand, the permissions for the contents of the group seem to be all ok at this point.

Yes, that's correct. As commented on a message above:

Note: the main permissions are the role permissions, so make sure that the user role has permission to post.

One thing is the user role, and another the OG role. OG role permissions don't override the User role permissions.
If a user doesn't have permission to post globally, then it won't be able to post neither on an OG.

This use case to illustrate what i consider a problem:

• GroupA = a group.
• ContentA = a group audience (content) of GroupA.
• I have given global permissions to anyone for posting comments (even anonymous).
• On the OG permissions i have given permission to post comments on GroupA and ContentA only to members.

What i expect:
that only the members would be able to post on GroupA and ContentA
and anyone can post comments on content types unrelated to groups.

What i get:
Only members can comment on ContentA
Anyone (even anonymous) can comment on GroupA.

In conclusion, only the global permissions are working for GroupA and not the OG permissions. As for ContentA, everything seems ok with this test.

Thank paean99! I see your point now.

Patch #57 seems to work perfect for me limiting permissions to post comments on Group content to non-members.

Thank you!!

Tried #57 with latest release of OG and 1.x-dev of comment_og, but comment approving doesn't seem to be working. The link for approving an unpublished comment is visible, but when trying to approve the comment I get access denied.

@aleksijohansson

Please check that the user that you are using have the right to approve comments.

@Blanca.Esqueda Do you mean the core permission for administering comments? The user I'm testing this with has the OG rights to approve comments. Is there some other permissions needed on top of that?

The #57 patch is also not working for me (latest 7.x-1.x-dev). Even if I give my group admin all OG Comment permissions, they are unable to edit or delete any comments.

Attached a new patch based on #57 with additional fixes for compatibility with OG 2.x. These include:

• Removal of $group->gid requirement from comment/$comment->cid/approve because it was not used any more and caused issues.
• Hide Reply link if comment is not published.

I found the patch didn't work if the 'Group content visibility' field was added to the Post type.

Leaving Group admins unable to view/approve comments.

Does anyone know of a fix for this?

hi all
It have been long time about compatibility with og2 and i would like to know if this is still in plans or if there is any other alternative.
Thanks