I have created a new group type called "Store" and have a content type called "Product" which can be added to store nodes. I want to only allow the store creator to be able to add products to the store. Currently a user can add a product to any store created by anyone.

On the OG Node Permissions page this is show:

In addition to the permissions listed here, the Commons Groups module grants non-group members the ability to post content into groups where content in the group is public.

This shows that this is how commons groups was designed but I want to know then how can I stop this behavior of allowing anyone to products in a store group.

Comments

doors’s picture

doors commented

I just want to know how to disable the feature of granting non-group members the ability to post content into groups where content in the group is public.

I want a group and it's content to be public but not allow persons who are not members of the group to be able to add content.

Can someone please provide some help.

rosemeria’s picture

rosemeria commented

Steps - finding OG permissions (create, edit, delete):
1) go to "configuration"
2) then "OG permissions overview"
3) select Node-group "edit"
4) permission list for all group-node types -- create, edit, delete

Checkout this support request issue too: Best way to keep content between authenticated users

These screen casts on OG helped me - http://modulesunraveled.com/organic-groups
Rose

doors’s picture

doors commented

@rosemeria Thanks for the reply.

I have already tried all of that but still once a user has the general permission to create a node type in this case "Product" they can add it to a group which it is set up to be added to in this case "Store" when the group is public.

I am using the "Domain Access" suite of modules as well and based on my research this is what might be causing the problem due to both OG and Domain Access using Node Access in different ways.

The following helped me out with getting private groups to only allow members to be able to post which was not possible before http://drupal.org/sandbox/kugta/1621090. Still though Public groups allow anyone to post no matter what the group permission is set to because the Commons Group module allows it and this message is shown at the top of the OG Node Permission page: "In addition to the permissions listed here, the Commons Groups module grants non-group members the ability to post content into groups where content in the group is public.". I want to know how to disable this feature that commons has implemented and I have tried to comment out the "commons_groups_og_user_access_alter" function contents in commons_groups.module file but it does not work.

dingo’s picture

dingo commented

It seems like this functionality is provided by Organic Groups but it is being disabled by Drupal Commons.

Maybe someone from Acquia can shed some light.

davidseth’s picture

davidseth commented

@doors, you mentioned that you commented out "commons_groups_og_user_access_alter()" and it didn't work. Did you clear your site cache as well as rebuild permissions? I rebuilt permissions after I commented out the function and now I can make public groups and remove the ability of others from posting.

Cheers,

David

geigerg’s picture

geigerg commented

Seems to be fixed per Organic Groups 7.x-2.2

WebSinPat’s picture

WebSinPat commented

yes, i'm trying to accomplish the same thing, "I want a group and it's content to be public but not allow persons who are not members of the group to be able to add content."
I have the various privacy modules enabled, added the visibilty fields, configured my permissions, so i am able to click some boxes that say non members should not be able to post, but it seems to be disregarded by commons. as mentioned above.
Should I comment out the function mentioned in #5? I usually try to avoid modifying code, was hoping for a configuration button.

davidseth’s picture

davidseth commented

@WebSinPat, the only way to get it to work like you want is to comment out that function. It isn't ideal, but I am hoping that if I get some time I can commit a patch that would make this configurable.

Kind Regards,

David

doors’s picture

doors commented

I too had to comment out the function to get it working. The thing is though that if you had created content in a group before that (Even after clearing the cache and rebuilding the permissions) you can still post in that group even if you are not a member but it won't work for new groups or groups you have never posted in before.

ezra-g’s picture

ezra-g commented
Status: Active » Postponed

I believe this will be addressed by #1961296: Refactor og_group_ref field per OG API improvements.

WebSinPat’s picture

WebSinPat commented

It does look like #1961296: Refactor og_group_ref field per OG API improvements would address my issue. It has been marked as fixed, and has a commit. Thanks for that.
I'm wondering should I apply the patches in the commit, or wait for an updated version of commons groups to be released? (I'm new to dealing with code still in development like this.)
Also, i'm unsure still how this fix would affect my site that has some existing groups i've already set up. Would I have to delete them and start new groups to get the functionality?

behoppe333’s picture

behoppe333 commented

Like WebSinPat, I am interested in this fix to Commons and new to the world of Drupal patches (or anything more complicated than using the recommended D7 release of a module). My situation may be simpler because I am building a new site (no old content). I look forward to preventing non-members from creating content and allowing members to post. Thanks everyone for comments on this topic.

ezra-g’s picture

ezra-g commented

As mentioned in #10, this will be fixed in Commons 3.3 as part of #1961296: Refactor og_group_ref field per OG API improvements.

If you'd like to test this functionality before 3.3 is released, you can package Commons locally with the command:

drush make build-commons-dev.make.

Commons 3.3 is expected to be released in late June.

behoppe333’s picture

behoppe333 commented

Thanks Ezra-g. That is great info. I wonder if you could provide a couple more things:

  • Any more info about getting that drush command to work? I am diving as newbie into drush so that I can follow your 3.3-testing advice. I can install modules etc. But, the command "drush make build-commons-dev.make" gives me scores of "ok" messages about checking out and cloning... Then I can't find a single new file. Help? (FYI: the command "drush make drupal-org.make" does produce lots of new files. Also, I asked a webhost provider for help and so far they are mystified by this; and I am observing this behavior on both webhosts I am testing.)
  • I also tried putting dev release of commons_groups into a brand new otherwise non-dev commons 3.2 site. I rebuilt permissions, got all excited by the UI when I edited a group, and then got the fatal error already reported here. Is there an easy workaround so I can get past this and get my hands on the access functionality of Commons Groups 3.3?

Many thanks

behoppe333’s picture

behoppe333 commented

FYI my webhost helpers got drush working for me. I have a running Commons Dev Release. :-)

It looks great and I can't wait for Commons 3.3 to go into production!

For those keeping score, drush finally worked per below (quoting Sr Tech Help):

The issue appears to stem from the fact that we have "fileinfo" disabled for the default PHP ( PHP 5.3 ) as a result of memory issues with fileinfo support compiled into that version. I've executed the drush command you provided using PHP 5.4 which is also available on your server and this resulted in successfully completing the command.

For your information I executed the command in the following manner:

drush make --php=/usr/local/php54/bin/php build-commons-dev.make

rgchi’s picture

rgchi commented

I'm having a similar issue that I've posted to Drupal Answers. I'm seeking to create a private, moderated group.

ezra-g’s picture

ezra-g commented
Status: Postponed » Fixed

This was fixed as part of the 3.3 release.

Status: Fixed » Closed (fixed)

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