Private doesnt remain checked

This sounds like a duplicate of #360460: rebuilding permissions makes private coherent_access nodes public. My recommendation would be to try the 6.x-1.x-dev version and apply the patches #360460: rebuilding permissions makes private coherent_access nodes public and #360651: Shared posts tab not showing on user account.

This is working well for me...hopefully these patches will be committed soon.

Let me try to restate the problem to make sure it can easily be confirmed. Configure coherent_access so new coherent_access posts are not private by default. Create a new post controlled by coherent access. Edit it, marking it private, has no effect - the post is still public and the checkbox is unchecked when the node is edited.

However, if initially configured so that posts are private by default, coherent access works fine. I can set the post public and/or private on subsequent edits and it works as expected.

The first patch by jseffel doesn't seem to fit the logical flow of the current hook_nodeapi function, glad to see its been dropped.

@jseffel, I don't understand what the second patch is supposed to accomplish, can you explain?

Ok. I think I see what @jseffel is getting at... The code logic incorrectly assumes that node access grants can be used to deny access, when in fact it only grants access.

    // shared_editing comes in via the form, coherent_access is via hook_node_api op='load'
    if ((isset($node->shared_editing['private']) && $node->shared_editing['private']) ||
        (!isset($node->shared_editing['private']) && $node->coherent_access['private'])) {
      $grants[] = array(
        'realm' => 'coherent_access',
        'gid' => $gids[0],
        'grant_view' => FALSE,
        'grant_update' => FALSE,
        'grant_delete' => FALSE,
        'priority' => 0,
      );
    }
 

I am not sure that this code is needed. It can probably be removed since the grant will never be written when view, update and delete are all FALSE (see http://api.drupal.org/api/function/node_access_write_grants/6), but I am not sure if there is any other reason to keep it?

Anyway, the code in hook_nodeapi doesn't work because the statement
$private = variable_get('coherent_access_default_node_private', 0); // load default node
just resets the private status to the coherent_access admin visibility settings. This is not what we want.

I think this line should be
$private = 1;

This seems to fix the problem.

Sorry. I see that the two patches overlap a bit. Its probably easy enough to apply the earlier patch and then go in and set $private = 1 to get the same effect. It doesn't really matter right now, because you are right - rebuilding permissions sets coherent_access nodes to private regardless of the coherent access admin settings. Need a way to distinguish between the absence of a row in node_access (indicating a private node), and a new node.....

I think the logic should be something like:

{see if the node is in the node access table.}  
      {if so, determine if a mode 0 blanket grant (gid $gids[0]) has been given.}
           {if so its not private, otherwise it is private}
 {else, its either a new node, or the node_access table is being rebuilt - use the default}  

If this is the correct logic, then the problem is

$result = db_query('SELECT count(*) FROM {node_access} WHERE realm = "%s" AND gid = %d', 'coherent_access', $gids[0]);

doesn't check to see if the node is in the node_access table.... it should be

$result = db_query('SELECT count(*) FROM {node_access} WHERE realm = "%s" AND nid = %d', 'coherent_access', $node->nid);

The line $private = variable_get('coherent_access_default_node_private', 0); then makes sense.

In testing this,
* new coherent access nodes are created with private status determined by the default settings
* private status works as expected
* rebuilding the node access table restores coherent_access nodes to default setting

I think this is the expected behavior...at least I don't see how it could behave otherwise without actually storing the $private setting in a coherent_access database table...

Patch against 6.x-1.x-dev .

Well. I had to use utdanning's version for the situation I was in. BUT it still had the email issue and "Shared Posts" tab did not appear on the user-menu. Lastly, the names of locally used functions did not begin with underscores. Oddly enough, when I added the underscores to the 'access callback' and its function definition, it fixed the missing tab.
So here it is....
Yet another fork of this very useful module.
I will attempt to devote some time to getting the initial module up to snuff, but in the mean time, any one is welcome to use this one.

A patch for the shared posts tab is already in the issue queue #360651: Shared posts tab not showing on user account.

Patch implemented as per #9 thanks, MGN