Specify a primary group which determine group context when node is in multiple groups.

there is some code there that tries to do the mnost sensible thing. what would be your rules here? we could show the group in the context of several nodes here. please see the $_SESSION['og_last'] code to understand what we do here.

i'm not too fond of that logic. there are plenty of valid reasons to se two nodes in a row, or see a node frm the subscribers page, or any other group page.

we already have that. it is called group_context. if a page is a group page, then og_get_grou_context() returns a group node.

In order to get rid of that ambiguity we need to ask the user which of his groups is the primary group and i don't think thats very sensible from a ui perspective for most sites.

If someone makes a clean patch with a reasonable UI, I will likely commit it ... This might be doable as a helper module. An analogous module for taxonomy is primary_term

Consider the scenario where a primary group has been specified, aliong with 3 other groups. Then an email notification goes and a different user clicks the link. This user got the notification because she belongs to one of the 'other' groups, not the primary group. In what group context should she see the msg? The primary group, or the one she belongs to?

any progress made on this? I am interested.

Nope - still awaiting a patch. Patch must be against HEAD/D6

Thanks. Do you have thoughts on what implementation path a patch should take?

TfR75,

I may have some time to work on a patch here. Not sure.

Do you have any thoughts on how this should be implemented? Simply a checkbox next to the available groups to allow a user to select a primary group? A weighting to allow for ranking of group priority? Plus a setting to turn this on or off? Other ideas?

As a bit of background, the reason I want this functionality is pretty simple. I am building a site with a breadcrumb, and I want to be able to control which group shows up in the breadcrumb for content items if the item is assigned to multiple groups. The only functionality I would look to provide would be that which lets a user select the primary group(s) for a node. Then I would provide a function that returns the primary group of a node. I would leave any further integration/development to others.

TfR75,

That sounds good. Just to clarify:

- Admin could turn primary group selection on/off
- Users could specify exactly one primary group
- Primary group could be returned via an api function

couple questions:

- how should this act if no primary group is selected? take the first (random) group and set it as primary? save no primary group? if the latter, should the api function to return a node's primary group return null? or should it return the first (random) group?

- suggestions on where to store the primary flag in the db? (is_primary tinyint(4) DEFAULT 0 NOT NULL on og_ancestry table?)

Here is an initial patch. Very simple:

- adds og_primary field to {og_ancestry} (tinyint, default 0, not null)
- implements admin setting to turn on/off primary groups. defaults to off. (wording is audience to be consistent, but I think this is confusing!).
- provides a select box of groups to select as primary audience under the audience check boxes and saves to {og_ancestry}
- persists primary group if in simple mode
- provides api function og_get_primary_group which takes a node and returns its primary group node if one exists

Trying to keep this simple as things could get complicated quickly if we try to do too much here. Comments? Thoughts? Questions?

Has anyone successfully applied this patch? Feedback would be great.

TfR75: I believe Drupal just chooses the group that gets fetched from the database first in the situation you are talking about. In reality, that isn't always the one you want to display for any given node.

Or do you mean when turning on the Primary Groups option on an existing site, rather than returning no primary group (NULL) for nodes where a primary group has not been selected, the API function should return the one that gets chosen [somewhat] randomly by Drupal?

This would not be too difficult to do. I would just need to change the API function to return current($node->og_groups) instead of NULL if a node has been assigned to groups but no primary has been set. Anyone else have an opinion on this?

Also, I see that in the code it refers to this group as the 'active' group in some comments. Should I update the patch to call this functionality selecting the 'active group' instead of 'primary group'? What makes more sense?

One other thing, I see this in the code:

/**
 * Set group context based on URL. Modules may override what we set here.
 * Set a custom theme based on what group is being displayed (if any).
 * Be smart about selecting the 'active' group for ambiguous urls like node/$nid
 * TODOL see http://api.drupal.org/api/function/menu_get_object/6
 */
function og_determine_context() {

It says 'Modules may override what we set here'. Does anyone know how? Or have a better idea what the author meant?

That mean, "modules may call og_set_group_context() whever they need to."

I'd love some patch reviews and collaboration here. Still a worthwhile feature.

The group thats chosen for context when someone views a cross-posted node is highly dependant on who you are and what your last page view was. There is no point in trying to maintain old behavior in this patch. Nodes created before this code exists should just have no primary group.

This looks like a good start. Here is a reroll, with some better language and minor fixes. Some outstanding issues an dcomments.

1. I think 'primary group' is the right terminology.
2. I don't see the primary group being used to set context for the page. i think that should be used if available, otherwise fall back to current logic. eventually, we might toss out current logic but i think we should keep it for now.
3. If only 1 group is chosen, should that group automatically be marked as primary? if so, the default value of primary form item should also come from $_GET['gids']. Furthermore, what to do when there is a discrepency between primary audience and audience? we handle situations like this elsewhere on this form using some smart javascript.
4. i want the primary group to be available in the $node object. That means it should be loaded during og_nodeapi(load). Thats what should be consulted in og_get_primary_group(), not the DB directly.

is anyone available to work on this? It is pretty close.

You should look at b2evolution. Here is a link to their demo site.

It is a multiblog engine that allows cross posting to different blogs.

View the attachment to see how they specify a primary group with radio buttons and additional groups with checkboxes.

Food for thought.

Hope that helps,
-Glenn

Subscribe

subscribe

I'm very interested to see this functionality implemented, mostly to help facilitate cross-posting support in the spaces_og module.

subscribing

subscribing, I'm all about this for spaces_og...

7.x first for concept/architecture discussion.

This sounds custom, and I think it can be solved easily outside of OG core:

1) Attach a checkbox field to a group, to indicate if it's primary.
2) When viewing a group contnet, iterate over the groups, and find the first one with the primary, and og_conetxt() that group.

What about adding a sort to the cached object returned via og_get_entity_groups() or in og_context_determine_context()?

og_context_determine_context() currently returns the first entity. Right now it's arbitrary as to how the result set, primarily from og_get_entity_groups(), gets ordered and is likely dependent on whatever storage system is returning the result set.

The other option would be to add a hook entry point into og_get_entity_groups() or og_context_determine_context() so that it can easily be delegated what logic should determine the primary group by sorting the $gids array when multiple potential contexts are possible.

While this may sound custom, the concept of greater control around a primary group association has been a recurring theme around many OG IA discussions I've been part of. The lack of increased clarity or more complete separation is why systems like Spaces simply cut out multigroup, and why some OG-driven systems replace multi-group with a content syndication/duplication system.

For that reason, even if OG Core does not address this, I think there needs to be a single, general-purpose solution that is the focus of the Primary Group concept. Perhaps it is in http://drupal.org/project/og_primary?

While this may sound custom, the concept of greater control around a primary group association has been a recurring theme around many OG IA discussions I've been part of

You are right, I can see the issue is going a few years back. But still I think it can be in contrib.

og_context_determine_context() currently returns the first entity. Right now it's arbitrary as to how the result set, primarily from

That's even a better suggestion than mine. Instead of calling og_context(), the "Primary Group" module can implement an og-context handler.

So for a D6 version, there's a couple ways to go. First, some kind of logic/alter hook/etc in og_context_determine_context(). Other possibility: The current -dev includes code that preempts og_context_determine_context() from running if a context is already set. This is a performance enhancement for sites using OG & Spaces, or similar systems that try to determine the context before og_init() is even fired.

This means a lower weight OG Primary module could have it's own logic--og_primary_determine_context().

ughh!! really not liking the D7 upgrade of d.org!!.. let's try this again...

wondering if any update/progress on this issue?

pretty sure this is the same use case i have; but just to be sure:

i need:
- primary og field (single, required, used to determine context and access control)
- secondary og field (multiple, not required, used to determine access, NOT used to determine context)

before i saw this thread i figured best approach was to modify og core to simply add a checkbox to the og field: "use in og context"; but then after reading through this i think possibly just a hook to allow contrib modules to alter might be more flexible. first approach however is certainly easiest ui for site devs.

as far as i can see there is no hook in to og_context_determine_context() for a contrib module to alter the result set. likely the best place to start.

I am guessing there is another solution for this but i haven't stumbled upon it yet.. so this patch was the simplest solution i could think of.. it simply adds a hook to allow altering the contexts returned in og_context_determine_context(). With that, and the set up i described above, i utilized this hook in a custom module like this:

function MYMODULE_og_context_determine_context_alter(&$data) {
  if (!is_array($data['node'])) return;
  $ids = array_keys($data['node']);  
  $results = db_query('SELECT id, gid FROM {og_membership} WHERE id IN (:ids) AND field_name = \'og_group_ref\'', array(':ids' => $ids));
  $valid = array();
  foreach ($results as $result) {
    $valid['node'][$result->id] = $result->gid;
  }
  // if we dont have any valid gids, i.e. the PRI was not set.. it is likely a node set up issue; but lets just return full result set in case it has values
  if (count($valid)) $data = $valid;
}

basically i discard any og membership records that are not from my primary og field

i also realized that og won't allow me to include the same group in 2 fields (it silently just discards the value and i end up with errors downstream). so i also added a form validation call to ensure my primary group was not in the secondary group.

This issue is quite old. I'm just wondering what the latest recommendation for selecting a primary group per group content instance is now.

1. Should this issue remain open awaiting a possible patch to OG core?
2. Is this something that should exist in a contrib module, or does it already somewhere?

My current solution with minimal code is to use a combination of suggestions in posts above from @Amitaibu and @jgraham.

• Use autocomplete widget, as it is draggable, for og_group_ref field and use group at index 0 as primary group (otherwise use checkbox with custom code)
• Call og_context_determine_context() to return primary group when setting og_context

EDIT: re-ordering of groups using the autocomplete provided by the OG Reference field widget does not work: #2335969: OG Reference widget autocomplete does not save the reordering of groups. The work around is to ensure that the primary group was the first to be added to the Audience Field. If not, the references need to be deleted and re-added in the desired order it seems.

Drupal 7 reached end-of-life and the D7 version of Organic Groups is no longer being developed. To keep the issue queue focused on supported versions, we’re closing older D7 issues. If you still have questions about using Organic Groups on Drupal 7, feel free to ask. While we won’t fix D7 bugs anymore, we’re happy to offer guidance to help you move forward. You can do so by opening (or reopening) a D7 issue, or by reaching out in the #og channel on Drupal Slack.

If this issue is still relevant for Drupal 10+, please open a follow-up issue or merge request with proposed changes. Contributions are always welcome! 💙