Using the og - spaces module, is it possible to limit what features are available to certain content types?

For example:
Say you have two Group content types, like Department Groups and Project Groups

In one group type you would only allow an image gallery and pressroom to be enabled/disabled.
In another group type you would only allow a calendar and casetracker to be enabled/disabled.

Is that currently possible?

CommentFileSizeAuthor
#12 og_features.jpg51.11 KBgmclelland

Comments

yhahn’s picture

yhahn commented
Assigned: Unassigned » yhahn
Status: Active » Fixed

Yes -- you can use spaces presets (see admin/build/spaces) to lock features at certain states. For example, you could create a "department group" preset and disable + lock all the features except for image gallery and pressroom. You could create a separate "project group" preset and do the other configuration.

Spaces_og ships with 3 preconfigured presets, but you can disable these and create your own.

Hope that helps!

gmclelland’s picture

gmclelland commented
Category: support » feature

If I understand you correctly, then these presets would be available to select when you create a group NOT when you create/edit a group content type?

I was hoping you could choose all the spaces presets available to select for each group content type. If that group content type had only one preset available, then it would be hidden/locked on the group create/edit page.

That way your Department Groups could be limited to only the Department Space Preset and your Project Groups could be limited to select say 1 of 3 other presets.

So I guess this is a feature request. Spaces Presets Per Content Type??

You could do this two ways:
1. A fieldset "Spaces Presets" on the group content type edit page which list all the presets with a checkbox next to them

2. A "group content types" fieldset on each Space preset edit page that list all the group content types with a checkbox next to them

What do you think?

-Glenn

gmclelland’s picture

gmclelland commented
Status: Fixed » Active

If I understand you correctly, then these presets would be available to select when you create a group NOT when you create/edit a group content type?

I was hoping you could choose all the spaces presets available to select for each group content type. If that group content type had only one preset available, then it would be hidden/locked on the group create/edit page.

That way your Department Groups could be limited to only the Department Space Preset and your Project Groups could be limited to select say 1 of 3 other presets.

So I guess this is a feature request. Spaces Presets Per Content Type??

You could do this two ways:
1. A fieldset "Spaces Presets" on the group content type edit page which list all the presets with a checkbox next to them

2. A "group content types" fieldset on each Space preset edit page that list all the group content types with a checkbox next to them

What do you think?

-Glenn

gmclelland’s picture

gmclelland commented

bump? any thoughts?

jmiccolis’s picture

jmiccolis commented
Version: 6.x-2.0-alpha4 » 6.x-3.0-beta4

Bumping the version here. There are still some good questions here.

mikemccaffrey’s picture

mikemccaffrey
he/him
commented

This would be useful functionality. We are currently using form_alter to hide the features we don't want groups of a certain content type to enable.

Grayside’s picture

Grayside commented

I wandered the code a bit looking at this, and it seems to me that what's being asked is almost like setting a spaces preset subtype.

When generating the preset widget, this is invoked: spaces_preset_form($presets, 'og'). It gathers up all the presets of type 'og'. If we could add a third parameter here, we could specify something else. For Spaces OG, subtypes probably make sense as being Content Types. For Spaces Taxonomy, subtypes might be vocabularies.

hefox’s picture

hefox commented

I'd also find this useful. I'd imgine at least by default features could define content types via the .info files, but I'd also imagine someone would like to override that (is there a way to to set spaces type key thing via the ui? I've only ever set it via the .info file. I haven't actually used much of spaces ui stuff much).

#1054236: Determine Preset Options per Group Content Type is somewhat relavent, in the context of differently stuff based on group content types.

Grayside’s picture

Grayside commented

You can set the spaces .info stuff via hook_system_info_alter(). Combined with a variable, it's doable to set via UI. Cleanup for features update is something else--whatever you set via that hook will end up in the .info file.

gmclelland’s picture

gmclelland commented

FYI... I think http://drupal.org/project/og_features is disabling available features per content types? You can see it in use by downloading Drupal Commons.

http://network.acquia.com/downloads/drupal-commons

hefox’s picture

hefox commented

Og features is for when not using spaces

gmclelland’s picture

gmclelland commented
StatusFileSize
new og_features.jpg51.11 KB

@hefox - I posted a link to that module as a proof of concept hopefully showing how something can be done in a similar way. Maybe it will give someone an idea on how to extend the spaces module? Some people might have never heard of the og_features module before.

In spaces you setup presets that define what features are enabled for that present. When you create a group node, you choose which preset you want for that group. Spaces will show you the full list of presets across all group types unless you form_alter what you don't need. I wish there was some easy way of specifying what presets a group content type can use. If there is only one preset, then the presets would be hidden from the users. I just don't know enough to make that happen.

Og_features shows all the og group types and allows you to configure what features are enabled/disabled for that group type as well as what features are always enabled/disabled for that group type. (see attached)

Anyways, that's just some observations of mine.

Grayside’s picture

Grayside commented

In spaces_preset_form() we need to add an access check alongside the disabled check.

spaces_features() then needs to be modified so it can process directives from the .info file such as spaces[type][og][] = "group". This would be a more complex alternative to the existing spaces[type][] = "og", in that there is another level of array structure to define relevant subtypes for the spaces type.

Then a spaces_preset_access() function of some kind would call spaces_features() and match the current form's context (i.e., node type) against the preset access rules. Doing this meaningfully might require sending the full form array as an option in spaces_preset_form()

A more generalized access framework might simply depend on hook_form_alter(). That would allow us to use the existing extensibility rather than growing this out in elaborate directions to also support per-preset user access/permissions.

Specialized UI to determine access rules should be handled as a separate request. It does not currently exist in Spaces and needs conversation of it's own.