Improve Content Type Administration by Organic Group so it can be deployed on groups.drupal.org

This topic has come up a few times, so I feel like we should figure out a generic solution instead of just moving these posts out of the group.

I proposed #438486: provide simple "remove from my group" or "remove from group X" feature but haven't had time to work on it.
I also like the idea of giving people more control over which posts they see. Group home pages can already be controlled by the group admin to show or hide different content types. But the http://groups.drupal.org/unread view and perhaps other places need a content-type filter exposed.

What else can we do to show you just the content you want to see?

This is also driving me nuts in the drupalchix group, where there is absolutely no reason to post jobs. There are many other such working groups (Views developers, for example) where this is also true and are probably an even bigger target.

What I really want though is not so much #438486: provide simple "remove from my group" or "remove from group X" feature (though that would be nice too) but a way to shut off the ability to post certain content types altogether at either a per-group basis (preferred) or a per-group-type basis (would also work, if "working groups" were exempt).

I picture an interface like this:

Or maybe even this if we wanted to get fancy:

I imagine there's some issue in the OG queue I should be chiming in on but I wasn't able to find it.

followed up with an infra issue http://drupal.org/node/994230

What do you think, amitaibu? Would you like to see this kind of UI in og.module or should we look to create this in a separate contrib?

@greggles,

OG6 doesn't have a real permissions system, so I don't think this feature should be in OG core.

OG7 does have a permissions system, however I've not included a "create" permissions since we can't know to which group the node is going to be assigned until the minute they click the save button. However, in OG7 package there is "OG content link" module that allows each group to set the available node links of that group (but a user can still override it by simple going to node/add/foo).

So, I think this should start in contrib.

I want what's in post 3 very badly. I know I'm going constantly have group members asking "Why would I ever want to create a ______ for a _____ group?".

Even just providing an easy way to turn them off for the og block would be very helpful.

The workarounds are muy kludgy.

Sounds like http://drupal.org/project/og_content_type_admin

Awesome work finding/suggesting that, Grayside.

Can anyone review that to see if it matches our needs? If so I can install it quite rapidly ;)

subscribe

[OT]: There are then job posts that should not post, if not in specific groups. For example, a job post for Australia where telecommute is not possible should not be posted on the Italy group. I have seen many of those job posts.

I understand that in this case, it's not simple to avoid those posts are posted in groups where they should not be allowed.

This pisses me off. Assigned. ;)

Sorry for the delay on this. I tested the 6.x-1.2 version of OG Content Type Admin against OG 6.x-2.11.

This module provides an admin screen that allows you to specify, for each content type, whether it should be available site-wide, forced for all groups, or optional for all groups:

Options here include:
1. Whether it is required "site-wide" (e.g. the Drupal default). This effectively means "Don't do anything special to these." A good example might be "Group" nodes and Pages.
2. Whether it is required within a group. This means an admin-enforced, all groups must have this content type available. "Discussion" might be a good example.
3. Whether it is allowed within a group. These will default to "on", but can be turned off by group admins on a new "Content types" tab on their group, like so:

The reason this works is because of the following:

1. The module uses hook_menu_alter() to monkey with the access permissions to node/add/foo. This means it's possible to even lock uid 1 out of posting content types, if you're not careful.
2. This also overrides http://api.drupal.org/api/drupal/modules--node--node.pages.inc/function/... to its own custom version to accomplish the same thing at node/add.
3. Finally, this module replaces OG's native "Group details" block with its own which has the options removed.

Or at least in theory; when I actually tested it this wasn't really working:

Things to watch that might impact g.d.o:
- There are only approximately 350 users of this module, and no attempt at a D7 port yet. :\
- Both Maintenance and Development status are "Unknown", with a last commit date of almost a year ago.
- On hook_enable()/hook_disable(), the module removes and replaces the default OG group details block with a custom one that filters out the options that shouldn't be there. Not sure if we've done any customizations to that block on g.d.o, but if so, this could cause issues.
- Until you adjust the settings at admin/og/og_content_types, any new content types on the site will be inaccessible to everyone, including uid 1.

In terms of a code review, I didn't delve too deeply, but here are my findings:

- While it's not conforming to the letter of the coding standards, it's not too bad. Indentation, query placeholders, curly braces around table names, etc. are in place.
- There are some issues with the lack of t(), for example: drupal_set_message('The og_content_type_admin table was updated'); I didn't thoroughly check for XSS holes, but not a bad idea.
- The code is surprisingly well-documented.
- There are issues with numerous notices when installed against a dev release of D6. This always makes me nervous with a new contrib module. Especially one on *.d.o.

My current recommendation is that this module mostly works, but not quite, and probably needs a good 2-3 days of focused attention/clean-up/testing before it could be deployed, including a review from the security team. Alas, I am not the person who is able to take this any further now. Unassigning self.

Thanks for the thorough review, webchick!

I'm moving this to the module's issue queue so these can hopefully be addressed.

It is tagged gdolove, so I can keep track of it.

It would be great if someone worked on this module. It has great utility, but I am wary about how it affects performance. Namely, it rebuilds the menu on every page. It is also not caching the results of a query (http://drupal.org/node/1156440)
that gets run many times per page.

I am closing this issue, which is for a not supported Drupal version.