neste link http://drupal.org/node/31601 e neste http://drupal.yale.edu/books/drupal-how-guide/taxonomy-access-control podemos encontrar informação valiosa sobre este módulo.
no entanto vou aproveitar este post para relatar a minha experiência com este módulo.
relativamente a cada categoria (ou categoria e sub-categorias) da taxonomia podemos definir os seguintes tipos de permissões por "role":
Mostrar - permite a visualização de nós da categoria sendo que os utilizadores deste "role" devem ter activa a permissão de acesso aos nós em admin/user/permissions#module-node.
Actualizar/Eliminar - permite a edição/eliminação de nós da categoria. os utilizadores deste "role" não devem ter activa qualquer das permissões edit any [type] content ou delete any [type] content em admin/user/permissions#module-node. dar permissão aqui significa que os utilizadores deste "role" vão poder editar/eliminar o conteúdo criado por qualquer utilizador dentro da categoria especificada.
Criar - permite aos utilizadores deste "role" adicionar a categoria na altura da criação ou actualização de um nó os utilizadores deste role devem também ter activa a permissão create [type] content em admin/user/permissions#module-node
Listar -
List: Whether this role can see the term listed on node pages and in lists, and whether the user can view the taxonomy/term/x page for the term. This does not control whether the role can see the nodes listed in Views, only the term.
View, Update, and Delete control the node access system. List and Create control the terms themselves. (Note: In previous versions of Taxonomy Access Control, there was no List permission and its functionality was controlled by the View permission.)
Permission options
View, Update, and Delete have three options for each term: Allow (A), Ignore (I), and Deny (D). Indicate which rights each role should have for each term. If a node is tagged with multiple terms:
Deny (D) overrides Allow (A) within a role.
Both Allow (A) and Deny (D) override Ignore (I) within a role.
If a user has multiple roles, an Allow (A) from one role will override a Deny (D) in another. (For more information, see section Good to know below.)
Create and List have only two options for each term: Yes (selected) or No (deselected). Indicate what each role should be allowed to do with each term.
Important notes
Custom roles will inherit permissions from the authenticated user role. Be sure to configure the authenticated user properly at admin/user/taxonomy_access/edit/2.
The Deny directives are processed after the Allow directives. (Deny overrides Allow.) So, if a multicategory node is in Categories "A" and "B" and a user has Allow permissions for View in Category "A" and Deny permissions for View in Category "B", then the user will NOT be permitted to View the node.
Access is denied by default. So, if a multicategory node is in Categories "C" and "D" and a user has Ignore permissions for View in both Category "C" and "D", then the user will not be permitted to view the node.
(If you are familiar with Apache mod_access, this permission system works similar to directive: ORDER ALLOW, DENY).
Global and vocabulary defaults
The vocabulary default, just underneath the vocabulary title, sets the permission that will automatically be given to the role, for any new terms that are added within the vocabulary. This includes terms that are added via free tagging.
The global default, at the top of the form, determines the grants the role receives for untagged nodes (including nodes with terms that are not in controlled vocabularies). Keep in mind that access is denied by default, so if you want TAC to grant a role access to untagged nodes, set the global default to allow for that grant and role.
Good to know
Users with multiple user roles: Allow/Ignore/Deny options are interpreted only within one user role. When a user belongs to multiple user roles, then the user gets access if any of his/her user roles have the access granted.
In this case, permissions for the given user are calculated so that the permissions of ALL of his user roles are "OR-ed" together, which means that Allow in one role will take precedence over Deny in the other. This is different from how node access permissions (for multi-category nodes) are handled within one user role, as noted above.
Input formats: Node editing/deleting is blocked, even when the user has Update or Delete permission to the node, when the user is not allowed to use a filter format that was used when the node was saved.