Permissions constantly re-setting themselves

I've had this problem in 4.6.

Its not every day, but it is the uncategorised permissions that seem to un-set themselves with the result that punters can't see uncategorised nodes. The first thing the helpful ones do is to report it to me as a fault (embarrasing). Other punters just go away (worse).

Can you check:
After submitting the 'category permission' page, try re-open it again. Does the permissions for uncategorized nodes are checked right?

If above is correct, there are two ways to change the permission every day:
- either the adminitsrator(S)
- or some kind of cron job.

I have not experienced anything like that. For me it sounds quite unbelievable.

In category permissions, all other values remain untouched?Something changes its setting in the database: either an administrator or a cron job of another module (I do not know about a module like that at all!).

As you told, it is not only changing the settings (table term_access), but also changes node access values in table node_access.
Are you the only administrator for permissions?

Maybe we can put a watchdog command to your TAC module to log when settings are saved.

I can confirm the described behavior in Drupal 4.7.2.

Does this fix solved this bug:
http://drupal.org/node/72663 ?

Does anyone have this bug since then?

I don't know yet, whether it is exactly the bug of this issue, but I have just had similar behaviour -- suddenly all uncategorized node's view permission became unchecked for both anonymous and authenticated users. I noticed after site's logs began to fill with access denied entries. I didn't make anything which may concern taxonomies or access control, was just experimenting with my theme and the views module. There were also no recent cron runs too.

I have only experienced this once (today), may be this will reoccur.
After enabling view premission back I manually restarted cron to see if something changes -- permission were intact.

By the way, it would be nice, if possible, to have a reason described in the log -- which one of the categories or vocabularies permissions denied the access. It took me half a day to figure out that all the involved nodes are actually uncategorized ones, and check the permission:)

PS.
System: Drupal 4.7.0 patched to 4.7.3.
MySQL: 4.1.21
taxonomy_access.module rev. 1.89
taxonomy_access.install rev. 1.5

Please try:
- If you resave given node - does it become accessable to users?
- On category permission page: does 'view' permission for "uncategorized" remain checked after this "bug" happens?

I'm also having this issue. 4.7.3, taxonomy access v1.89

I've set uncategorised nodes to "view" for every user role. Every few days the permissions on every one of those roles resets, all users get access denied errors, and I have to go back into each one to reset it manually.

I'm only running drupal standard cron.php and it doesn't coincide with running that.

I cannot figure out what event resets the permissions for uncategorized nodes.
(Did you add a new user role, when this bug happened?)
I still cannot regenerate it.

When you experience this bug (but before reseting eg. view permission):
1. can you check if following query output any rows in database: SELECT * FROM `term_access` where tid=0 ?
2. Does this bug only "resets" uncategorized" permissions ONLY? All other term permissions are untouched?

(Did you add a new user role, when this bug happened?)

No

When you experience this bug (but before reseting eg. view permission):
1. can you check if following query output any rows in database: SELECT * FROM `term_access` where tid=0 ?

No worries I check that next time.

2. Does this bug only "resets" uncategorized" permissions ONLY? All other term permissions are untouched?

_only_ uncategorised yes, for all roles.

This happens to me on a 4.6.3 install I have every time I make a change to any taxonomy vocabulary. It resets all of the Uncategorized nodes permissions for all roles.

I have not been able to recreate this bug in 4.7.3 using the TAC module version 1.89 from Aug 4th.

bluecobalt: Thanks for comment! :)
I gave me the clue! When a taxonomy term is deleted, it delete tid=0 rows from table "term_access", instead of deleting the row regarding the given term.

There was an error in hook_taxonomy.
$edit is not an object, but an array. Wow, i wonder how could this bug stayed in the code from the old TAC module!

line 754:
Wrong:
db_query("DELETE FROM {term_access} WHERE tid='%d'",$edit->tid);
Good:
db_query("DELETE FROM {term_access} WHERE tid='%d'",$edit['tid']);

I figured out what made this confusion.

In 4.6 in hook_taxonomy:
$edit was an array in 'insert' and 'update', but it was an object in 'delete' op. This was totally illogical.

This changed in 4.7.

Thanks very much for sorting this so quickly. I applied the changes manually, so hopefully you won't hear from me again!

Awesome! Glad I could be of help. I'm really glad that this bug is now gone. This is an important module for the sites that I'm working on. Thanks!

It seemed for me a very strange bug, it was difficult to find the cause of it.
I hope it's gone completely.