hi,

on my drupal 5 site, after disabling the taxonomy access control (TAC) module, users are not able to edit their own nodes, it shows 'access denied' messages,

how to restore the node access permissions like it was before installing the TAC?
OG node access is enabled on my site.

can I clear the node_access table?

thanks,
enky.

Comments

Christefano-oldaccount’s picture

Have you tried rebuilding permissions in Administer » Content management » Post settings ?

Node access status

If the site is experiencing problems with permissions to content, you may have to rebuild the permissions cache. Possible causes for permission problems are disabling modules or configuration changes to permissions. Rebuilding will remove all privileges to posts, and replace them with permissions based on the current modules and settings.

Rebuilding may take some time if there is a lot of content or complex permission settings. After rebuilding has completed posts will automatically use the new permissions.

    http://example.com/?q=admin/content/node-settings

Hotlikecold’s picture

If you are using a blog api to post articles and this set's of your post settings rebuild (and turns off your site to anonymous user) then click administer permissions for authenticated users to YES.

This should take care of it.

http://newsmediamagazine.com/

gbhatnag’s picture

In my Drupal instance (5.1), under Home › Administer › Content management › Post settings - I do not have the option to rebuild the permissions cache. That entire message about there being potential problems just isn't there. The weird thing is, I've seen it there before and I've used it... can you only do it once?

My front page is acting weird and and the post settings do not seem to make a difference (i.e. changing the teaser length makes no difference) and new users to the system are having problems editing their accounts. Also, in IE 7, the front page style is completely messed up, though every other page seems to work just fine.

Any other ways I can rebuild the permissions cache? Could there be something else that is causing these problems?

Thanks.

texas-bronius’s picture

I had similar troubles on my end. I believe the Rebuild Permissions must be part of TAC, b/c I don't see it as an option in Publish Settings either, and I haven't got TAC installed on my site in question... I tried all kinds of things and even went and forced a call to node_access_rebuild() which did in fact empty out my node_access table to one record, but didn't resolve my issue.

What finally worked for me in my particular case was allowing editors "Full HTML" rights (because my pages are Full HTML, not filtered).

Hope this helps

--
http://drupaltees.com
80s themed Drupal T-Shirts

v8evoluzione’s picture

I'm having similar problems. If I follow the advice here and go to /admin/content/node-settings, this leads me to the afore mentioned post settings but with no rebuild cache button!

Can anyone shed any light on this for me please?

Thanks.

Christefano-oldaccount’s picture

The Rebuild permissions button won't appear if your node_access table only has one row in it -- or if you haven't enabled an access control module. I suppose you could try rebuilding the table manually with node_access_rebuild() but I'd do it on a backup first.

<?php
  node_access_rebuild
();
?>
ursus@drupal.ru’s picture

I've cleared node_access table and clicked on Rebuild permissions button but nothing changed - users still have no access for editing own nodes :(

SethM’s picture

So, I ran into a permissions problem all my access controls were set properly, but my users couldn't edit any content that was created though they had the permissions for it. I was banging my head against the wall. It turned out that input formats also have permissions, and if not set properly give an access denied error when trying to edit the content. So i went into "Site Configuration > Input Formats" and set my permissions on "Full-HTML" to allow my users access. Low and behold it worked. Filtered HTML defaults to let all users use it., where as "Full HTML" and "PHP Input" default to "No user roles may access." Just a FYI, hope this helps someone out.

Seth Martin
freeStyle Media
Missoula, MT
http://freestylemedia.net

As If’s picture

But I thank you for posting your findings. You have relieved a headache. It's all about allowing the Full HTML setting.

My clients will just have to live with this bizarre limitation for a while, until I get the time to hack this puppy...

-------------------------------------------
Interactive Worlds and Immersive Obsessions
http://www.asifproductions.com

-------------------------------------------
Interactive Worlds and Immersive Obsessions
http://www.asifproductions.com

EvanDonovan’s picture

I would guess you should be able to change the input format to Filtered HTML by running a SQL query on one of the node tables, but I'm not sure on which field.

That way, your content might look a little different, but you wouldn't be giving regular users the ability to use the insecure Full HTML input format.

Online Publications Editor,
UrbanMinistry.org
http://www.urbanministry.org/user/evandonovan

superturboultra’s picture

This was it. Taking over a site from someone else, who thought it was a good idea to make PHP the default input type, then went on to make the entire site in PHP mode... (slapping forehead)

If anyone has any idea how to change a batch of nodes to Full HTML instead, I'd be very grateful :)

As If’s picture

Using PHPMyAdmin or some other db admin tool (or by examining a dump of your db), look at the values in the filter_formats table. This will tell you which format ids (integers) correspond to which format names. For instance:

INSERT INTO `filter_formats` VALUES (1, 'Filtered HTML', ',1,2,', 1);
INSERT INTO `filter_formats` VALUES (2, 'PHP code', '', 0);
INSERT INTO `filter_formats` VALUES (3, 'Full HTML', '', 1);
INSERT INTO `filter_formats` VALUES (4, 'Rich Text', ',,', 1);

In my example, PHP code is format id 2 and Full HTML is format id 3 (this is the standard arrangement). Take note of which format ids you want to change, then go to the node_revisions table, where you can run a command like this:

UPDATE node_revisions SET format = 3 WHERE format = 2;

-------------------------------------------
Interactive Worlds and Immersive Obsessions
http://www.asifproductions.com

mblazke’s picture

Yes, I'm another member of the Forgotten-InputFormats-Permission Club ;-)
Thanks 2 freeStyle_Media (Nov28,2007)!

matt_harrold’s picture

Thankyou so much, I was tearing my hair out trying to find a solution to this problem until I read your post which fixed the problem immediately.

A big fat virtual Aussie beer for you!

Tasmanian web developer.

gottsman’s picture

I always seem to forget about the input format permissions set. This worked for me as well once your comment kicked on the light bulb.

streetdaddy’s picture

yet another person that would love to buy you a beer, if I could! A simple thanks will have to suffice...

tanjerine’s picture

another very happy drupal user over here. thank you sooooo much for posting this. i just spent the last 2 hours trying to figure out why my access control permissions weren't working.

i'd buy you another beer, if i could.

sarah azurin
php developer | drupal developer | book worm
linux registered user #318168

jweedman’s picture

Fixed my issue, and the whole 'banging my head against the wall' issue as well.

Thanks for the post.

cam8001’s picture

Thanks for this. I was bitten by this years ago, and worked it out then - but I'm not sure it would have taken me to figure out all over again if not for your post!

ardi1983’s picture

This is really a fantastic community!

He who dwells in the shelter of the Most High will rest in the shadow of the Almighty. I will say [b] of the LORD, "He is my refuge and my fortress, my God, in whom I trust. Surely he will save you from the fowler's snare and from the dead

dgtlmoon’s picture

Heres a curly one, a clients site was getting similar symptoms

Somehow the node_access table ended up looking like..

mysql> select * from node_access;
+--------+-----+-------+------------+--------------+--------------+
| nid    | gid | realm | grant_view | grant_update | grant_delete |
+--------+-----+-------+------------+--------------+--------------+
| 157355 |   0 | all   |          1 |            0 |            0 |
| 154501 |   0 | all   |          1 |            0 |            0 |
| 154746 |   0 | all   |          1 |            0 |            0 |
| 155396 |   0 | all   |          1 |            0 |            0 |
| 156134 |   0 | all   |          1 |            0 |            0 |
| 156135 |   0 | all   |          1 |            0 |            0 |
| 156443 |   0 | all   |          1 |            0 |            0 |
| 156921 |   0 | all   |          1 |            0 |            0 |
| 157109 |   0 | all   |          1 |            0 |            0 |
| 157110 |   0 | all   |          1 |            0 |            0 |
| 157307 |   0 | all   |          1 |            0 |            0 |
| 157319 |   0 | all   |          1 |            0 |            0 |
+--------+-----+-------+------------+--------------+--------------+
12 rows in set (0.00 sec)

An old backup looked like..

mysql> select * from node_access;
+-----+-----+-------+------------+--------------+--------------+
| nid | gid | realm | grant_view | grant_update | grant_delete |
+-----+-----+-------+------------+--------------+--------------+
|   0 |   0 | all   |          1 |            0 |            0 |
+-----+-----+-------+------------+--------------+--------------+
1 row in set (0.01 sec)

i ran...

mysql> insert into node_access values (0,0,'all',1,0,0);
Query OK, 1 row affected (0.00 sec)

and everything seemed to work again... what would cause this?
dgtlmoon drupal devel

richard.e.morton’s picture

Regards

Richard Morton
NaFoF webmaster - Multi-Activity Clubs in the UK
Built with Drupal, Views, Calendar, Suscriptions, TAC

aklump’s picture

admin/reports/status/rebuild