No list or create permissions on any terms may result in incorrect use of default on save

Be sure you are using the latest version, as there were major bugs in 6.x-1.0.

Edit: I re-read the earlier posts in your forum thread; the part about anonymous users getting view does seem bugged. If you can provide screenshots of your TAC configuration and steps to reproduce the behavior (ideally, from a clean drupal install) using 6.x-1.2, then please set the issue to "active" with that information. The results of devel's node access review would also be appreciated. See the troubleshooting documentation for instructions on using devel.

Regarding the absence of terms in the node object, that is a design behavior. Review the documentation for the List and Create permissions. The user does not have access to the terms without Create; therefore, they are not present in the node object at that time. They are cached internally in TAC and restored in hook_nodeapi() when the node is saved.

Thanks very much for your quick followup. Just one more thing: what is your TAC configuration for anonymous and authenticated user roles? If you have time to add screenshots for those roles as well, I can hopefully duplicate your setup to debug.

I confirmed this bug from a clean install. Steps to reproduce:

1. Create a role.
2. Create a user and grant the user the role from #1.
3. Create a vocabulary.
4. Add a term to the vocabulary from #3.
5. Configure TAC as follows for Anonymous:
   Global Default: A/I/I/no/yes
   #3 Vocab Default: D/D/D/no/no
6. Configure TAC as follows for Authenticated:
   Global Default: A/I/I/no/yes
   #3 Vocab Default: D/D/D/no/no
7. Configure TAC as follows for the role from #1:
   Global Default: A/I/I/no/no
   Term from #4: A/A/I/no/no
8. As user 1, create a node tagged with the term from #4.
9. Log in as the user from #2, edit the node, and save.

The node access records will now be corrupted and the node will be viewable by anonymous users.

I believe this bug will require the following changes to fix:

1. hook_db_rewrite_sql(): Remove create op. Return if on a node edit page.
2. hook_form_alter(): Set #access to false for terms with no create privs. Replace with optgroup if it is a parent term?
3. hook_nodeapi()
   Validate op: Notify user that the term cannot be added/removed.
   Update op: Do not allow addition or removal of terms for which the user does not have create.

Attached patch implements the changes in #8 (more or less) and fixes the original issue. I'd appreciate any reviews or testing, because this is a pretty major change.

I did some testing with various sorts of vocabularies and different combinations of create and list in the term hierarchy, and both create and list seemed to behave properly in each case I tried.

This also fixes #112307: Cannot create node in taxonomy term without create permission for parent term and should fix any lingering issues like #660668: TAC + revisioning: Empty taxonomy term select list on node/add for regular users. It's worth noting that, because of #112307: Cannot create node in taxonomy term without create permission for parent term, we will need to provide a hook_update_N() to go with this patch for users who for whatever reason have create checked for a parent term but not its children.

I realized a weakness of this patch: I don't think it will work with Content Taxonomy or any other module that alters the taxonomy form, modules that TAC currently supports. There are definite advantages to using hook_db_rewrite_sql(), despite the problems it also causes. We'd definitely need at least a check of the user's allowed terms in the presave case (instead of the current method).

It's unfortunate that there is no way to set #access on a per-option basis, otherwise we could provide a very simple method to use with other modules. Instead, however, the whole form element has to be overridden. This is a problem with FAPI that persists in D7.

In any case, I think any solution along these lines might need to go in a separate branch. I will look into an alternate way of patching this particular bug in the current branch.

I think I found the root problem for this particular issue:

function taxonomy_access_node_access_records($node) {
  $grants = array();

  if (is_array($node->taxonomy) AND count($node->taxonomy)) {
    /**                                                                         
     * @todo                                                                    
     *    How does deny/ignore work with this?                                  
     */

    // ....
  }
  else {
    // Use the default for nodes with no category 

This uses $node->taxonomy, but _preserve_terms() and _restore_terms() modify the db records directly. So, their alterations are not in $node->taxonomy. The queries don't actually use the data from $node->taxonomy, so as long as the records in the DB are correct by this point, the query will work properly. Just need to actually use the right query.

I wonder if it is possible to use one query regardless of whether the node has terms or not? The current difference is that we use an inner join to {term_node} and then a left join to {term_access_defaults} in the first query, but only an inner join to {term_access_defaults} when the taxonomy is empty.

A workaround might be a simple query to check {term_node} directly. The only other option is to not use hook_db_rewrite_sql() for create, as in #9.

Discovered a related bug in the course of troubleshooting #12: #902858: Node records sometimes corrupted after removing all terms from the node

I've confirmed that the patch in #902858: Node records sometimes corrupted after removing all terms from the node is another way of resolving this issue.

Reverting the scope of this issue because the original problem has been fixed in #902858: Node records sometimes corrupted after removing all terms from the node.

A new issue for changing the implementation of create, as suggested both in the forum thread from the OP and in various @todo in TAC's codebase, is here:
#903522: Move control of create into hook_form_alter() and hook_nodeapi() to prevent numerous problems