What I'm trying to do is allow a user to create a node and assign a taxonomy term to it. The problem I'm encountering occurs when the user assigns a term that they aren't allowed to view. After creating the node, they are unable to view it. Is this by design? If so, is there any way for me to allow users to always be able to view the nodes that they create? (Other than forcing them to select a term that they are allowed to view, that is.) Or am I just missing something here?

Comments

cpugeniusmv’s picture

What happens when you assign the "edit own NODE-TYPE" permission to the user? It might override the node access API and let the user view his own posts (and edit them, which may not be desirable in this situation).

jonathan_w’s picture

Thank you for the quick reply. Yeah, I had tried your suggestion, but it didn't work. If the user types in the correct URL for editing the node, they can actually edit it. But if they type in the URL for viewing the node, they get an access denied error. Since I was doing this in connection with another module, I thought it would be good to test the behavior without the other mod in the mix.

What I want to accomplish is for a user (who doesn't belong to any roles) to be able to create a node and assign a term to it so that only certain roles can view (but not modify) that node. But I want the user to be able to view and modify the node they created. I was able to replicate the problem with a regular Story node. Here's the steps I took to reproduce it (sorry, there's some extraneous steps):

  1. Create 2 roles: Role1 and Role2.
  2. Create 2 users and assign each of them one of the roles: User1 - Role1 and User2 - Role2
  3. Add a vocabulary (TestVocab) and select the Story content type for it.
  4. Add 2 terms to the vocabulary: Term1 and Term2.
  5. On the User Permissions page, make sure the following 4 permissions are checked for both users:
  • create story content
  • delete own story content
  • edit own story content
  • access TestVocab vocabulary
  • On the Taxonomy Access Permissions page set the following permissions for the TestVocab vocabulary:
  • anonymous user
    *default*: View = D, Update = D, Delete = D, Create = unchecked, List = unchecked
    authenticated user
    *default*: View = D, Update = D, Delete = D, Create = checked, List = checked
    Role1
    Term1: View = A, Update = I, Delete = I, Create = checked, List = checked
    Role2
    Term2: View = A, Update = I, Delete = I, Create = checked, List = checked
  • On the Post Settings page, rebuild the permissions.
  • Create a story node with User1 and assign Term2 to it.
  • User1 is now unable to view the created node (gets access denied), but is able to edit it if the correct URL (/node/#/edit) is entered in the browser. User2 can view the node just fine, but is unable to edit it (which is how it should work).

    So, have I set up something incorrectly? Or have I turned up a bug? Maybe what's needed here is some sort of "access own NODE-TYPE content" permission, since all we have right now is a simple "access content" permission. Or is that functionality supposed to be handled by the "edit own NODE-TYPE content" permission?

    allentseng’s picture

    try

    function taxonomy_access_node_grants($user, $op) {
    - return array('term_access' => array_keys(is_array($user->roles) ? $user->roles : array(1 => 'anonymous user')));
    + $grants['term_access'] = array_keys(is_array($user->roles) ? $user->roles : array(1 => 'anonymous user'));
    + $grants['node_author'] = array($user->uid);
    return $grants;
    }

    function taxonomy_access_node_access_records($node) {
    while ($row = db_fetch_array($result)) {
    $grants[] = array(
    'realm' => 'term_access',
    'gid' => $row['rid'],
    'grant_view' => ($row['grant_view'] == 1) ? 1 : 0,
    'grant_update' => ($row['grant_update'] == 1) ? 1 : 0,
    'grant_delete' => ($row['grant_delete'] == 1) ? 1 : 0,
    'priority' => 0,
    );
    }
    + $grants[] = array(
    + 'realm' => 'node_author',
    + 'gid' => $node->uid,
    + 'grant_view' => TRUE,
    + 'grant_update' => TRUE,
    + 'grant_delete' => TRUE,
    + 'priority' => 0,
    + );
    return $grants;
    }

    xjm’s picture

    Status: Active » Closed (duplicate)