TAC troubleshooting

If you are experiencing issue with user permissions not behaving as you expect when you configure Taxonomy Access Control (TAC), try the following troubleshooting.

TAC, Core, and Contrib

Make sure the user does not have administer nodes permissions. This permission overrides any TAC configuration.
Check the input format the node is in. If a user does not have permission to use a given input format, they will not be allowed to edit any nodes that use that input format, regardless of other access control settings.
Check your core permission configuration at admin/user/permissions: How to configure permissions at admin/user/permissions for use with TAC
Review the suggested core permission configurations for each grant type in the module documentation.
Check to see if the user has other roles that may be granting other permissions. Remember: Deny overrides Allow within a role, but Allow from one role can override Deny from another.
Review the configuration for authenticated users at admin/user/taxonomy_access/edit/2. Remember that all custom roles also have the authenticated role.
Check the configuration of any other enabled access control modules, or disable them. Grants from different access control modules are always "OR-ed" together; that is, if another access control module grants a user access to a node, TAC cannot revoke that grant (and vice versa).
Note: To use multiple access control modules together, you may wish to consider the Module Grants module. See: #695376: How give term-based Taxonomy Access Control VIEW DENY over type-based Content Access VIEW ALLOW.

Views 3 and comment views

As of this writing, views' comment views do not respect the node access of the parent. The current workaround is to add the filter (Content) Content access: Access to these views. See #1222324: Fix query access control on relationships (comments) for more information.

Freetag vocabularies

As of this writing, freetag vocabularies do not work properly with TAC. See:

Troubleshooting with Devel

You can use the Devel module to examine your node access table:

Install Devel. Enable both Devel and Devel node access at admin/build/modules.
If you are not logged in as user 1, go to
admin/user/permissions#module-devel_node_access
and grant the appropriate role the view devel_node_access information permission.
Go to admin/settings/devel and check the box for Devel Node Access debug mode.
Go to admin/build/blocks and enable the Devel Node Access and Devel Node Access by User blocks.

Now you should be able to view the node access information for any node on the node page, as well as a sitewide summary at devel/node_access/summary. Even if you do not understand the information Devel gives you, it can be very helpful if you choose to submit an issue to the module's issue queue.

Cleaning up corrupted node access records

If the devel module indicates that there are problems with node access, or if you suspect another node access module may have corrupted your node access data, try the following.

Rebuild node access permissions at admin/content/node-settings/rebuild.
If that does not resolve the issue, try disabling and re-enabling TAC.

If it seems TAC's configuration is still bugged, try completely removing and reconfiguring TAC:

Note: these steps will remove your existing TAC configurations. Do not do this on a production site.

Disable the module at admin/build/modules.
Uninstall the module at admin/build/modules/uninstall.
Re-enable the module at admin/build/modules.
Rebuild node access permissions at admin/content/node-settings/rebuild.

Advanced users: You can also do this much faster with Drush using the following command:

drush dis taxonomy_access -y;\
drush pm-uninstall taxonomy_access -y;\
drush en taxonomy_access -y;\
drush php-eval 'node_access_rebuild();'

If you paste this at your command prompt and hit enter, you will see:

$ drush dis taxonomy_access -y;\
> drush pm-uninstall taxonomy_access -y;\
> drush en taxonomy_access -y;\
> drush php-eval 'node_access_rebuild();'
The following extensions will be disabled: taxonomy_access
Do you really want to continue? (y/n): y
taxonomy_access was disabled successfully.                           [ok]
Content permissions have been rebuilt.                               [status]
The following modules will be uninstalled: taxonomy_access
Do you really want to continue? (y/n): y
taxonomy_access was successfully uninstalled.                        [ok]
The following extensions will be enabled: taxonomy_access
Do you really want to continue? (y/n): y
taxonomy_access was enabled successfully.                            [ok]
Content permissions have been rebuilt.                               [status]
$

Submitting a support request or bug report

If you think you have found a bug in TAC, try searching the issue queue. There's a good chance others may have encountered the same bug, and if so, there may be workarounds or patches available to fix it.

You can also submit an issue to the issue queue. It will save time and help others answer your questions if you include the following information:

The specific versions of Taxonomy Access and Drupal Core you are using.
Whether you use MySQL or PostgreSQL.
Steps to reproduce your problem
What of the above troubleshooting you've tried, and what the results were. (Especially the information from Devel.)
Screenshots of your configuration pages for Anonymous, Authenticated, and any role in question are very helpful. (Screenshot the forms at admin/user/taxonomy_access/edit/1, admin/user/taxonomy_access/edit/2, andadmin/user/taxonomy_access/edit/x.) Please review your issue or comment after you've submitted it, to double-check that the screenshots are actually attached and available for others to view.