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.

Thanks for the reply. Could the $_SESSION['og_last'] code be wrapped in 'if (og_is_group_type($node->type){' so that the group context is only set if the prior page view was a group? That way if a public node is viewed off the front page there is no group context.

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.

I see your point. What would be nice though would be a way to distinguish 'group pages' versus clearly 'non-group pages' such as the frontpage or search results. I'll play around with the code some and see what I can come up with.

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.

I don't think it is bad behaviour that a user can see that a node belongs to a specific group, but what does puzzle me about the scenario outlined above is that user A can not be sure which group user B is taken to.

Example: I publish content to one of my groups, but think it could also be interesting to other groups I am a member of. This could then lead to the node being shown in one of the other groups - annoying in a case where I want to make it obvious where the content originated from.

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.

I can see your point, but then I do have the opposite problem with my users. I often get complains because people say their content should be marked as belonging to the group they posted it to and not to some other group. The node, of course, belongs to several groups, but themes, the group details block etc. only relate to one group. And this constantly annoys my users because they do not understand it. And it can even be hard for the admin if themes and groups are connected.

Would it be possible to have an option to enable a primary group setting? Then people like me and jcruz would be happy and your users would not be bugged by a cluttered interface...

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

Okay, we will look into this!

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?

I think this will depend on the context of the respective website. For our site, it would be important to make sure where the content originated from, so I would choose that options. For others it may be that they think it should be the group the user is subscribed to - but that approach also has problems: what happens if you are subscribed to all the groups a node belongs to, just not the primary group?

So, after thinking about this I would say primary groups should be made an option; and those who chose it will then also set in which context the node is displayed. This also helps where group association of nodes controls the themes - in that case it would be crucial to set which group a node 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?

We had to change the way groups are set up on our system which made other development work more important than looking into this. I still think it would be a useful feature to add but I doubt that we will be able to commit development time within the next few months - though happy to take part in discussions and testing until we have resources available.

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.

Kingmoore, I would vote for the simple check box. A weighting, I think, would only make sense if there was a clear scenario in which it would add real benefit. For breadcrumbs etc. you would only want one group to be displayed. More functionality, such as a weighting, is always nice, but I agree with Moshe's previous comment that the UI should be kept as simple as possible. Which is why I also think that the admin should have the choice on whether to activate the feature at all. If you don't need it it will only confuse users.

So my preference would be a check box (or perhaps a drop down field to ensure that there really is just one primary group) together with a setting for the admin to turn it on/off.

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.

This may be too late to be of use but here are my thoughts, just in case:

Currently, OG seems to pick a group (I am not sure how it does that, maybe based on creation time of the group) and display the node in the context of that group. If an admin wanted to activate primary groups for their site then the module could just use this group as a primary group. So in a way that would be the functionality as it currently stands but it would allow admin and/or user to change the primary group if they felt it was important.

Thanks very much for the patch! Unfortunately, I cannot test it at the moment as we are still running Drupal 5 and I do currently not have a test system.

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?

Currently, OG does actually do something like a primary group, by, as you say, picking one group as the group in which context the node will be displayed. What I meant to suggest was that when the new Primary Group feature is introduced to an existing site this group could become the primary group if it was necessary to define one for every node - taking this approach would not actually make any (visible) change to the system as the node would still be displayed in the context of the group it was in before. But it would allow users who are not happy about the group to change that. New nodes would only get a primary group if one was assigned to them.

Another way of doing it would be not to have a group as the primary one when the new feature will be introduced to an existing site. The disadvantage could be that with large sites admins/users would then have to designate a primary group for each node.

Maybe administrators could choose one of the two option when they introduce Primary Groups to an existing site?

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:

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.