Add 'All Group Nodes' checkbox for OG - group node context

Try this patch. Added an "OG - group context" condition. Just a simple checkbox that will satisfy if any group is set.

@djdevin - I haven't tried the patch yet, but from geerlingguy's comment, it would be nice if you could provide an update function to clear the cache so the new condition is available immediately.

#1 patches cleanly with patch -p0 < patchfile (-p0 cause it adds a new file to /plugins). And adds a new condition 'OG - group context', which works as promised.

But as discussed on IRC, it would be more intuitive for the user to only have one group type-related condition (probably should stay 'OG - group type context' to distinguish from 'OG - group node context'), and have something like the following radios:

( ) Not in a group
( ) In any group type
( ) In specific group types

And JS-hidden checkbox options for $og_types would appear below (and save values) only when the 'In specific group types' is checked.

Will add a hook_update after we can get #5 implemented - this should be the way to go.

I'm just getting started with context API but it seems like we need to override get_contexts() in the context_og_condition_group_type class to accept multiple arguments. Currently it will accept no group, or a type of group (and there would never be multiple matches) - if we want it to accept "any" group, we'll also have to send in the detected type so it will work with the selective options.

Let's say we have the following group types: school, class, club

I think we should maintain the ability to configure a context to match nodes that are either in no group OR a group of type "school." So the JS-hidden check boxes for group types would still need to include "Not in a group."

And, then, the "Not in a group" would be a radio button above, and also a checkbox below. The UI is starting to sound confusing.

@marcp: I didn't realize this was the existing functionality. The language "Not in a group" made me think that if checked, the condition would be true not in any group context (and none of the other selected groups would have any affect). It might be clearer to say "Not in selected groups".

But now that i know the intended functionality - continuing my proposal to merge these two conditions - how about adding a 'Negate' checkbox (the way rules.module handles conditions):

1. Something like this would be true if we are in any group context:
   

   [ ] Negate condition 
   If checked, the condition returns TRUE, if it evaluates to FALSE.
   
   (o) In any group type
   ( ) In specific group types
   

2. And this would be true if we are not in specified group type contexts:
   

   [√] Negate condition 
   If checked, the condition returns TRUE, if it evaluates to FALSE.
   
   ( ) In any group type
   (o) In specific group types
   [ ] Type 1
   [ ] Type 2
   [√] Type 3
   [√] Type 4
   

Alternately we could just keep the "OG - group context" as a separate context (maybe in that case rename to "OG - any group context"). It would be easier to develop (it's already basically done, except for negation option, which i think would be helpful no matter what). But I'm guessing users would find these conditions more meaningful if these could be selected together.

Yes, it would, but I think more complicated to do :)

We came up with this mockup that might work - while keeping the group selection checkboxes to not break existing functionality.

Thanks everyone for the mockups - it's really useful to be able to see them. It still seems like it's going to be confusing on the configuration side of things if we're going to try to use that one condition for all the different use cases.

I'd like to run this by some more folks who actually configure contexts but who maybe don't write code.

The current functionality, while not ideal, lets you configure a condition that will hold for any group content -- as long as no new content types are added that are designated as group nodes. Does that make sense (and is it really true, because I haven't configured an OG context lately)? You should be able to check all the group checkboxes and not have to revisit the configuration unless you add a new group content type.

Another question I've got is whether there are other complex context condition forms at this time. Context helps take some of the pain out of configuring sites, so it makes sense for us to keep the UI as simple as we can. Maybe that means stuffing all the OG conditions into a single condition, but maybe it means keeping them separate.

I'd love to see any patch here that would make the end user's context configuration experience easier. And it would also be great, when the patches roll in, to update the README.txt because the one that I've got in there now is pretty weak (sorry about that).

I agree that while the negations may allow for greater flexibility, they'll also add an extra level of complexity and confusion. I propose a modified version of the UI in comment #11, with the addition of an "In selected group types" radio button (as suggested in comment #9). The checkboxes would be disabled for the "In any group" selection, and active for the "Not in any group" and "In selected group types" radio buttons. This would allow for the scenario @marcp describes in comment #8.

To clarify, the options would be:

( ) In any group

• When selected, the context will be active for any post in any group on the site.
• No further options are available

( ) Not in a group

• When selected, the context will be active if the page/post is not in any group.
• The "group types" checkboxes are available.
• For example, the "Not in a group" radio and the "club" group type are selected. This condition will be met for posts that are either in no group, or in a group of type "club".

() In selected groups

• When selected, the context will be active if the post is in a group of one the selected types.
• The "group types" checkboxes are available.

My first thought was that adding an "OG - Global" condition with a single "In any group" checkbox was the way to go here, but now I'm on the fence. I think maybe it would be least confusing to keep all this logic in the same place. Thoughts?

penguininja's suggestion is a nice idea, but I think it's still too confusing without seeing an actual screen mockup. Radio buttons to me mean that it's "one of these and not any of the others" but in this case, the additional group types checkboxes are going to be available if either "not in a group" or "in selected groups" is selected.

Even more confusing is the "not in a group" radio button, which also lets you choose group types. I'm not saying that the current version isn't also confusing, because it is, but I think we still need to improve on the usability.

And I'm not in a rush to commit anything because, as far as I can tell, the functionality is all there, it's just ugly. I'd almost rather get the documentation in place for what's there first before we change it.

@marcp I can definitely see your point, my suggestion in comment #13 got quite complicated as I was drawing it out :-/ My thought was that because you would never want to choose both "In any group" and "Not in a group" (essentially creating a sitewide context), that these belonged as a "one of these and not any of the others" radio set. But with the addition of the "in selected group types" option and the group type checkboxes, this is no longer very intuitive.

Perhaps the best way forward is the additional condition with the "In any group" checkbox, and a description noting that when this option is selected it will override any other OG conditions set. This is much more simple/intuitive then the conditional logic structure described above.

To indicate why this use case should be addressed in comment 12 marcp says

The current functionality, while not ideal, lets you configure a condition that will hold for any group content -- as long as no new content types are added that are designated as group nodes. Does that make sense (and is it really true, because I haven't configured an OG context lately)? You should be able to check all the group checkboxes and not have to revisit the configuration unless you add a new group content type.

That is correct, however the issue with why "In any group" is a desired option is in the case where you have group content types and functionality defined by features that may or may not be enabled. Hopefully the following scenario will provide clarity;

Let's say we have the following features modules that provide group node types;

1. my_feature_grouptype_a
2. my_feature_grouptype_b
3. my_feature_grouptype_c

Additionally we have a context that should be active if content is in *any* group type, but we don't want the site admin to have to enable all three grouptype features to use our context. That is, we want our context active anytime we have content in any group type but we don't care what type it is. Right now we have two options;

1. Create a hard dependency on our context feature on all three grouptype features. This is undesirable because the site builder/admin may only want the functionality from grouptype_a and grouptype_c.
2. Alternatively we can build our context to trigger on all three group types. However, if all three grouptype features are not enabled our context will appear as overridden since features will want to prune the spurious unavailable options

Regardless of which "solution" above we used for building our context we still could not protect against the site admin or site builder adding other group types, but the context should still trigger.

Regarding the UI discussion it seems that the following UI makes sense;

( ) indicates unselected radio
(o) indicates selected radio
[ ] indicates unselected checkbox
[√] indicates selected checkbox

Scenario 1:
( ) In any group
(o) Following group details
    [√] Not in any group
    [√] in TYPEA
    [ ] in TYPEB
    [√] in TYPEC
 
Scenario 2:
(o) In any group
( ) Following group details
  checkboxes disabled or hidden
    [ ] Not in any group
    [ ] in TYPEA
    [ ] in TYPEB
    [ ] in TYPEC

However, I'm not sure that this is any better than the following;

[ ] In any group
[ ] Not in any group
[ ] in TYPEA
[ ] in TYPEB
[ ] in TYPEC

With the above the end user can effective create a global context with the following combinations;

1. "Not in any group" AND "In any group"
2. "Not in any group" AND selecting all group types

Do we really need to protect against that scenario?

Regardless it sounds like better documentation would be helpful.

Attached is a patch against D7 that provides the functionality as described in the last case in comment 17 it is intended to be applied after the following patches;
#1019386: Port to drupal 7: http://drupal.org/files/d7_port-1019386-25.patch
#1319954: are views and og_views really requirements?: http://drupal.org/files/context_og-1319954-3.patch

Committed to 7.x setting to be ported to address D6