User roles can't edit 'uncategorized' nodes

You have to give permissions for user_roles on admin/access page: either: e.g: 'create story', 'edit own story', etc. Or for all node types: 'administer nodes'.

>it should work if some of the pages aren't assigned a taxonomy. Right?
Right, it should work. These are 'uncategorized nodes'.

Did it solved your problem?

Ok. so you have a problem with "update" permission for 'uncategorized' nodes.
I did not understand.

-Can you check if view, and delete permissions work for 'uncategorized' nodes for given user role?
-When you submit category permission page, does it save the settings all right for 'uncategorized'? (Go back to the same category permission page of the given user role, and check it).
- If you disable and then enable the module on admin/settings/taxonomy_access, does it solve your problem? (It makes a complete 'housekeepin' of the node_access table, which controls eg. update permission for nodes)

This bug is real, I just experienced it. Designated roles (without administer nodes permission) cannot edit stories flagged with the appropriate taxonomy UNLESS all posts are categorized. Any ideas how to fix this?

I might be seeing a similar problem on 4.7:

When I set a node's term via the database (i.e. I write an SQL UPDATE/DELETE/or INSERT on the term_node table), the access permissions work intermitantly.

Sometimes they work, but if I change the node's term (via a module I'm working on) all the permissions break. I can return to having correct permissions by disabling and renabling the module.

While I only have 1 node (thus my problem is not having some node uncategorized), the symptoms sound very similar.

-M

Ok. I think I'm on to something. The problem is with this block of code in nodeapi (at least in 4.7)

    case 'insert':
      // Determine the category/categories the new node was assigned to
      db_query('DELETE FROM {node_access} WHERE nid = %d AND realm = \'term_access\'', $node->nid);
      // For nodes not assigned to a category
      if (!is_array($node->taxonomy)) {
        dprint_r("Now I think the node is not catgorized");
        $result = db_query("SELECT * FROM {term_access} where tid = '0'");
        while ($row = db_fetch_object($result)) {
//          db_query('INSERT INTO {node_access} (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (%d, %d, \'term_access\', %d, %d, %d)', $node->nid, $result->rid, $result->grant_view, $result->grant_update, $result->grant_delete);
          db_query('INSERT INTO {node_access} (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (%d, %d, \'term_access\', %d, %d, %d)', $node->nid, $row->rid, ($row->grant_view == 1 ? 1 : 0), ($row->grant_update == 1 ? 1 : 0), ($row->grant_delete == 1 ? 1 : 0));
        }
      }
      // For nodes assigned to a category
      else {
        $tids = array();
        foreach ($node->taxonomy as $term) {
          if (is_array($term)) {
            foreach ($term as $tid) {
              if ($tid) {
                $tids[] = $tid;
              }
            }
          }
          else if ($term) {
            $tids[] = $term->tid;
          }
        }
        dprint_r("Past categorized/uncategorized split");
        // Query the term_access table to get the permissions for the new node's assigned category/categories
        // then make appropriate changes to the node_access table.
        $result = db_query("SELECT rid, BIT_OR(grant_view) AS grant_view, BIT_OR(grant_update) AS grant_update, BIT_OR(grant_delete) AS grant_delete FROM {term_access} WHERE tid IN ('".implode("','",array_values($tids))."') GROUP BY rid");
        while ($row = db_fetch_object($result)) {
          db_query("DELETE FROM {node_access} WHERE nid=%d AND gid=%d AND realm='term_access'", $node->nid, $row->rid);
//          db_query('INSERT INTO {node_access} (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (%d, %d, \'term_access\', %d, %d, %d)', $node->nid, $row->rid, $row->grant_view, $row->grant_update, $row->grant_delete);
          db_query('INSERT INTO {node_access} (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (%d, %d, \'term_access\', %d, %d, %d)', $node->nid, $row->rid, ($row->grant_view == 1 ? 1 : 0), ($row->grant_update == 1 ? 1 : 0), ($row->grant_delete == 1 ? 1 : 0));
        }
      }
      break;
  }
}

For starters: terms are objects. Note how we now need:

else if ($term) {
            $tids[] = $term->tid;
      }

Secondly, the bit_or aggregate function performs strangely. Expected behavior:

+------+
| col1 |
+------+
|    1 |
|    1 |
+------+
sql> select bit_or(col1) from testing group by col1;
+--------------+
| bit_or(col1) |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)

However if we have a table with values other than 0 and 1 in the bit_or'd column we get:

+------+
| col1 |
+------+
|    1 |
|    1 |
|    2 |
+------+
mysql> select bit_or(col1) from testing group by col1;
+--------------+
| bit_or(col1) |
+--------------+
|            1 |
|            2 |
+--------------+

The term access table has values other than 0 and 1 in it's grant_* fields I think we are getting really weird responses. (I think it is behaving the same as the MAX aggregator function).

I'm not sure exactly what the fix is. There are two possibilities. Should the node_access table only have values of 0 and 1, or should this block of code be written to do something else.

Advice?

Ok. I figured out my problem, at least.

This method runs at during the nodeapi function. It assumes that all changes to the taxonomy will have occurred by the time the update code runs.

My module changes the terms of the node by calling taxonomy_node_save during the insert/update phase as well. My code must run after and/or not change the taxonomy of this object.

Sadly, taxonomy_node_save does not call any hooks nor does it call the more generic node_save. Arg.

I take back (some) of my earlier critiques of TAC. Attached is a patch that fixes at least one issue: terms as objects.

-M

The module still seems to only let designated users edit posts randomly. I'm not sure why it is behaving so erratically. I have tried emptying the node_access and term_access tables and rebuilding them by enabling the module, but it doesn't seem to help. Mfredrickson, do you think this is related to the problem you found? Could you post your patch?

Also, I have the problem both in drupal 4.6 and cvs.

I will try to check this bug.

BIT_OR: is bitwise OR. (You have to group by another column, not the one, that you need the OR operation for)

+------+
| col1 |col2
+------+
| 1 |1
| 1 |1
| 1 |2
+------+
mysql> select col1, bit_or(col2) from testing group by col1;
+--------------+
| col1 | bit_or(col2) |
+--------------+
| 1 |3

+--------------+

That is OR operation for 1,1,2 is 3. It is a binary OR that is BIT_OR: 01, 01,10 is 11. That is 3.

For arvana's problem, i found the bug in function _refresh_node_access_table().
- The SQL query did not fetch values for grant_update, grant_delete.

(Bug is fixed for both 4.6 and 4.7).

I mark issue 'fixed', since orginal bug reported by arvana is fixed.

mfredrickson: If your problem persist, please create another bug report.