Posted by Anonymous on February 24, 2013 at 7:41pm
When users setup a group I want them to have the option to set public or private. For public groups I want site members to be able to join without approval. For groups designated private by their creator, I want the option for the group administrator to require approval before a site member can join.
This seems possible by allowing the group creator to set/override default group permissions. But as there is a long, long list of permissions exposed in my case, I doubt a casual member who creates a group could navigate to the permissions options and select/deselect the require approval subscription option.
In OG 6 it seemed like this was an easier settings option when a group was being created, am I missing something?
Comments
This can be done
The easiest way to do this would be to have two different group type, one that is public and one that is private. You could set up all of the presets for each and they would only choose one or the other and the default settings would do what you want.
That said, if you want to do this with only one group type, that can also be done.
It's true that set up for this is more difficulty than it was in Drupal 6, but it is more flexible. It used to be you had one main setting when creating the group, but now you have to go to Configuration/OG Field Settings and turn on the fields that you want for permissions and roles.
The good news is that once you set this up for the group, (for example, adding the group visibility field to your group type) you can expose check boxes in your group creation form that shows defaults and can be overridden without going to the permissions page. You can simply set the group visibility field to be visible and editable by whoever is creating the group. Hope thast helps.
Thanks for the ideas
Thanks gettysburger, I will definitely try the two group types. Never thought of that but it seems like a great way to get the isolation needed for all sorts of aspects of the private groups such as keeping them removed from views etc.
I am finding the 7.x-2 og entity references very difficult to decypher, especially in the settings for views. More user friendly descriptions would be welcome.
trainingcity, we are working
trainingcity,
we are working on the similar requirement and having hard time with customising OG for private communities. we are using panels and views to display the group content.
Currently, the way its working is only if group owner add a user to the group then only they could access it(no way to show a request option without compromising the content privacy). Please let me know if you have figured out any solution for access request by implementing any of the above solutions suggested by gettysburger
And one more access issue we came across is that we have a document content type for groups and the file system locked down to provide access for logged in users only. But if logged in user has the doc url he can download the document.
Thanks!
OG 7.2 or 7.1?
druser:
Are you using 7.2 or 7.1. I am finding 7.2 extremely difficult to configure with Views. It is basically impossible if you don't know exactly what you are doing, very unforgiving I would say.
OG 7.1
We are using 7.1 and planning to migrate to 7.2 if it solves any of these issues. Your comments are very helpful, if that is the case then we will stick to 7.1 for a while.
Migration from 7.1 - 7.2
It was a nightmare to migrate from 7.1 to 7.2. There was no upgrade path other than getting into the db and making many, many, manual changes to the tables. If you are running 7.1 I definitely do not recommend you even think about 7.2 unless/until an upgrade path is available.
Bottom line on 7.2 from user perspective:
Better integration with other entities, for example you can easily setup a menu on content types that allows the user to create new content that is automatically associated with the group node they are viewing.
Potential improvement to Views. However, and it is a big however, the cryptic nature of the views relationships and contextual filters makes it impossible to get things done.
Migration from 7.1 is a nightmare. Do not try this at home... Very difficult. There are a couple of recipes to help in the issues queue.
If 7.1 is working, I would leave it alone.
Cryptic nature of the views relationships and contextual filter
Thank you, very well put.
You wouldn't perhaps be referring to the OG members admin view ? I've been struggling trying to get this into a panel for theming purposes for user admins of their own members.
Between Ctools task plugin overrides, problems of exposed form filters, views bulk operations and whatnot. The added value of all this gets lost somewhere in translation!
Cat,
wondering if this is will be better documented in v.8 :-)