The issue: when cloning a group and adding children to the new group with a rule, node_save puts the node id of the origin of the cloning in the og_group_ref of every child.

We have got an OG group, called 'case'. On creating a case, the user can automatically create a number of sessions that belong to the new case. We use a rule for that with custom PHP code:

function create_session($i, $case, $uid) {
	$node = new StdClass();
	$node->type = 'session';
	node_object_prepare($node);
	$node->title = "Session $i";
	$node->language = LANGUAGE_NONE;
	$node->uid = $uid;
	$node->status = 1;
	$node->created = time();
	$node->changed = $node->created;
	$node->field_session_number[LANGUAGE_NONE][]['value'] = $i;
	$node->op = t('Save');
	node_save($node);
	og_group('node', $case, array('entity_type' => 'node', 'entity' => $node));
}
$uid = [node:author:uid];
$case = [node:nid];
$nr = [node:field-number-of-sessions];
$nr = intval($nr);
for ($i = 1; $i <= $nr; $i++) {
	create_session($i, $case, $uid);
}

This works OK, when creating a new group node. Then we decided to give our users the ability to clone an existing group, using the node clone module: https://drupal.org/project/node_clone
The idea: an existing group is cloned and after that the rules script would create an number of sessions for the newly created case.

The odd thing was that the sessions that were created by the rule became member of both groups, i.e. the origin of the cloning and the new case. We tracked it down to the node_save line in the script. Debugging statements:

	echo "new case = $case<br />\n";
	echo "node->og_group_ref[LANGUAGE_NONE] before node_save: ";
	var_dump($node->og_group_ref[LANGUAGE_NONE]);
	 
	node_save($node);
	 
	echo "node->og_group_ref[LANGUAGE_NONE] after node_save, before og_group: ";
	var_dump($node->og_group_ref[LANGUAGE_NONE]);

Leading to this output:

new case = 2993
node->og_group_ref[LANGUAGE_NONE] before node_save: 
null
node->og_group_ref[LANGUAGE_NONE] after node_save, before og_group: 
array (size=1)
  0 => 
    array (size=1)
      'target_id' => string '1129' (length=4)

2993 is the node id of the new case. It is the only node id that is passed to the rule. But on the node_save, og_group_ref suddenly gets the value 1129, which is the node id of the origin of the cloning. We were really surprised to see the 1129 pop up here, because that node id was only used in the previous action (the cloning).
The effect was that every new session was attached to 2 groups: 1129 (added by node_save) and 2993 (added by og_group). Of course, this is not what we wanted to achieve.

We found a workaround, by setting the value of og_group_ref before the node_save:

	$node->og_group_ref[LANGUAGE_NONE][]['target_id'] = $case;

Yet, this should not be needed. How can we do this properly without the workaround?
array (size=1)

Comments

Jan-E’s picture

Ping. Anybody got a chance to see why node_save puts a value into og_group_ref of a new, cloned node?

shushu’s picture

Status: Active » Postponed (maintainer needs more info)

Trying to get into this might be too complicated, considering this situation include not just OG, but also Rules, and node_clone, and your own code.
My first guess is that node_clone doesn't do a clean job cloning, and some reference to the original node stays there. If you can try to verify it by cloning a node and printing it out (using dpm() maybe), it might be a good starting point.

Jan-E’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (won't fix)

Closing this issue, because the workaround works around.