Deleting a taxonomy term results in a non-editable node

I'm unable to reproduce this. Could you provide some more specific steps to reproduce the issue?

Yeah, see, the steps in #2 do not reproduce the issue for me. :) So that's why I need some more details on your configurations, etc. If you could start from "1. Install Drupal 7.10 and Taxonomy Access 7.x-1.0-rc1," that would be ideal.

I'm getting the error below when attempting to publish a page/node that was previously saved as unpublished:
You may not remove the following tags from field_tags: 35

Using Drupal 7.21 with Taxonomy Access 7.x-1.0-rc1 for a site that has 60+ users creating pages, I've configured a basic page content type for an admin and one for an authenticated user. Authenticated users are organized by group (12 groups/total). Each group is a "Role" and users in a group can only edit or delete their own group's pages/nodes. Both basic page content types have a taxonomy group dropdown for user group names and another taxonomy group dropdown for each group's sidebar content ("none" is the default if a group does not have sidebar content). When an authenticated user creates a page a selection is made for their group and another for their group's sidebar content (if any).

TAC is configured so only a user's group name (dropdown #1) and group sidebar content (dropdown #2), if any ("none" is default), can be selected (other 11 choices are grayed out).

When an authenticated user uses the basic page content type for users, selects his group, selects his group's sidebar content (or not), keeps the page unpublished, clicks save ("unpublished" watermark's visible), THEN goes back to publish the page, gets the error message: "You may not remove the following tags from field_tags: 35". The error message is referencing/highlighting the group sidebar content taxonomy (dropdown #2).

Is this a permissions issue? Can I configure TAC as I have (to limit users site group and content selections to their own group), save a page as unpublished for later publishing and not get this error? Do I have TAC configured wrong?

Thanks for any advice, suggestions, tips

I recently had this problem -- i.e., not being able to delete nodes with a term reference field that was referencing a deleted term. (Incidentally, I'm not sure it's a TAC problem.) This is how I solved it.

Let's say you have a term reference field (foo_field), and it's referencing a taxonomy vocab (foo_vocab), which contains the term, bar, with a tid of 666. The bar term is then attached to numerous nodes via foo_field.

However, in a fit of drunken existential clarity, you realize that bar is an irrelevant categorical distinction, casting absolutely no light or clarity on the nature of your content's relationship to foo and, as such, you sulkily delete it from foo_vocab (and then head to the bar... literally... for a well gin and tonic, because they're on special for $1.50). This leads to the present predicament of not being able to delete nodes once associated with the bar term via foo_field.....

So, the next morning, nursing a wicked hangover, you set about to fix this problem by going to the field_data_field_foo_field table in the database, searching for and deleting every row with 666 in the field_foo_field_tid column. Then you repeat this exact process in the field_revision_field_foo_field table, before heading out for a little hair of the dog in the form of a bloody mary and loaded nachos at your local Applebee's.

Voila... problem solved (at least it worked for me, except that I never eat at Applebee's).

Anyway, I offer this in hopes that it may help someone.

I wish I could "like" a comment in the issue queue. Because if I could, I would like @cossimo's a thousand times.

Hello,

I have the same issue. My system:
# Drupal 7.38
# Workbench Moderation 7.x-1.4
# Taxonomy Access Control 7.x-1.0-rc1

In our system the normal Worker (who can add and edit content, save drafts) get this error if saving the node as draft. An admin user can save without problems. I think I should read the comment from cossimo in detail....

Matroschker