I've got the latest OG installed and running fairly well. But I want to be able to restrict groups to the type of content they can create. Right now the Group Details menu that shows when you enter the group context allows creation of all content types, period. I don't want that. I only want them to be able to create a subset. Will I need to use Taxonomy to restrict that? Or can I administer the OG menu like other menus (doesn't seem to be the case).

Thanks,

Steel Rat

Comments

ditek’s picture

Basically you need to create new roles under Access control, then find a way to assign groups to these roles. Check out OG Roles and OG Promote, they may, or may not, solve your problem, depending on the complexity of your access control scheme.

Steel Rat’s picture

Thanks for the reply,

I do have OG_roles installed, though ended up not using it. OG Promote looks interesting. Do you know if the role is context sensitive? What I want to do is give the creator of the group a specific role, and subscibers a different role. But those roles shouldn't be persistent. Meaning if the go back out to the main page their role should revert to authenticated user. Likewise if they go into another group they belong to, but did not create, their role should not retain the Group Creator role.

Does that make sense? Can't find much documentation on the OG_Promote module to tell if this is the case.

Thanks,

Steel Rat
Drupal Site: RPGMapShare.com

Natalie@drupal.ru’s picture

You won't be able to create node types that your role doesn't allow you to. For example, if forum topics can be posted in OG but an authenticated user doesn't have a permission to do so than no one in that role would be able to create forum topics, and on OG home page either (it wouldn't show on the block). But this has to be restricted by role, not by OG group.

Steel Rat’s picture

Seems like it would be more appropriate for the Group manager to dictate what type of content can be created by whom in his or her group. This essentially means access control independent from the main site access control which only affects members of the group.

Something like this would make OG SO much better, in my opinion. And one could expand upon this and have the group manager allow named access to select content within a group. Example, Group Manager creates a document, but only wants it visible and perhaps editable, by George, read-only to Fred, and not visible to anyone else in the group.

If there is a Drupal module that already allows this, I'd love to see it, but it would need to integrate with G.

Steel Rat
Drupal Site: RPGMapShare.com

drurian’s picture

That would be a nice feature, but hardly possible due to the limitations of the current Drupal access control system. I mean, you can't even limit what type of contents are viewable or editable by what roles.

bonobo’s picture

The simple access module lets you configure view/edit/delete by role.

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

bonobo’s picture

Try a combo of role based access to node types, og_roles, and the admin settings for limiting what node types are available to groups ("Omitted content types" at admin/settings/og ).

Create one role that has access to each content type, and make sure to give the role an intuitive name (ie, if the role governs access to pages, name the role page).

Keep in mind, the bulk of your permissions will be assigned through the authenticated user role -- these special roles will only govern the ability to create/edit node types.

If you need additional node types, use flexinode/cck/content-o module, or clone the story node as described in the handbook. While this won't scale for dozens of nodes, it will work pretty effectively for a smaller number.

Hope this helps.

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

Steel Rat’s picture

I don't think any role-based access control will get me where I need to go, as described above.

I do use CCK and most of the OG modules, but finding adequate documentation is the difficult part. Trying to find out exactly what OG_Promote does, for example. Is the promotion temporary, in effect only within the context of that group, or is it permanent as long as that group is in effect, no matter where on the site the person is? If it's temporary, that will solve one part of the problem. But without the ability of the group manager to assign an instance of a node to a named user, I can't get there. And that assignment should allow read/write but not delete access.

Here is the specific scenario. I'm trying to move my Role-Playing game forums to Drupal. Each GameMaster will create a group for his/her game. Then he will creat player character sheets using a CCK node. The GM needs to be able to assign a specific character sheet to one of the group members so they can edit it, but not delete it. He also needs to be able to say this sheet is assigned to this person, and only the GM and the person can see it.

Similarly, the GM might want to start a forum topic that only selected group members can see and reply to. Roles just won't do it.

Steel Rat
Drupal Site: RPGMapShare.com

spjsche’s picture

Did you ever solve this issue, as I am trying to implement a similar sort of scenario.

Thanks
Stephen

Steel Rat’s picture

No, I gave up. I still have the site, but I was trying so many things it just became a mishmash. I might start over with 5.x and see if things are any better. But if permissions are still only role-based, then I doubt I will be able to get there. I need true distinct groups which allows for both role-based and user-based permissions, and an admin who's permissions do not leak outside the group.

Steel Rat
Drupal Site: RPGMapShare.com

spjsche’s picture

I managed to implement something similar using the OG blockvisibilty module.

Say you have two groups, one of which is called "Group A" and another "Group B".

Create two content types say "Daily News" and "Reports"

Then add two menus, one called "Create News Item" and another "Create Report"

In the administer menus, assign "Daily News" to "Create News Item" and "Reports" to "Create Report".

You now see the two menus we added in the blocks section.

Enable the "My Groups", "Create News Item" and "Create Report" say to show on the left side of the theme.

Configure the "Create News Item" using the "Group Visibilty" to only display this option when you choose "Group A", and the same for the "Create Report" to only show when "Group B" is chosen.

As long as a user is only a member of one group then, you have what you want.

Hope this helps for starters.

femrich’s picture

This sounds like the only solution that here that actually addresses the original problem-that the groups menu cannot be configured and offers links to all content types--even those that are fully disabled so far as I can tell. Unfortunately, OG Block Visibility is not available for 5.x. Oh well.

Steel Rat’s picture

Wouldn't work for a true groupware environment. Site members could be members of any number of groups, and owners of any numbers of groups. OG is not nearly robust enough to do this.

I've since found ways where I could almost get to where I need to be, but all the work would have to be done by me every time someone joins a group. No way I'm going to do that. I need each group to be completely encapsulated and independent of each other, and as such permissions allowed in one group to not bleed over into the site and other groups. And the group own needs broad administrative capability within the group that he may not have outside it.

Steel Rat
Drupal Site: RPGMapShare.com

yesman123’s picture

Drupal 5.0 is the same. All the types (create product, story, poem etc) appear on group details menu. I was surprised that there is no way to remove or filter them out. All I want is 'create content' in the group details menu, not those many types I created for the views.

femrich’s picture

Perhaps Content Type Admin by OG would do the trick? http://drupal.org/project/og_content_type_admin

spjsche’s picture

That is why I am still on 4.7, and cannot move to 5.x because of no Block Visibility.