Brad blogs about this solution on the Aten Design Group blog.

The next logical step was a few other admin override options to nodes. Brad once again shares this information with the Drupal community on their blog.

All of this to say that Drupal really needs to break out these permissions more such that distributed management of content types by various backend staff/business units independently. This should all be done without grating staff rights to do things we don’t want them to do (i.e. “administer nodes” permission).

Thanks to Brad and Aten Design Group for the help.

We have been bumping up against the fact that in Drupal you have to have the Administer Nodes permission in order to see unpublished nodes. The down side is that it means users in the role with Administer Nodes permission can see ALL nodes. Not ideal for our implementation.

Thanks to the fabulous folks as Aten Design Group, Brad (beeradb), created a custom module that fills this very needed gap in Drupal 5.x. I’m hoping they will decide to release the module and someone in the community can maintain it. From what I had seen in the community a need for this functionality truly exists and many can benefit.

Keep up the great job Brad and the rest of the Aten Design Group folks. Y’all are top shelf.

SimpleTest: Because clicking on forms is for suckers
Session Discussion (Courtesy of Lullabot)

Well, a quick check of the access control records proved that anonymous users did in fact have the Access Content permission. Hmmmm…. what else could it be.

As a side note, originally on pages where the user was denied access all you got in the content body was a “2″. No access denied message, just the numeral “2″. Thanks to the good folks on irc #drupal-support it was found this this is typical of an access denied issue. Atleast that led us down the right path.

Long story short, the tac_lite module had been previously installed on this site but was no longer being used. Apparently the disabling of the module did not properly clean up the node access data.

Again, thanks to the great folks on #irc, this time BDragon, and a quick search on drupal.org, the solution was easy. The default access row was missing. Adding the following to the table resolved the issue:

INSERT INTO node_access VALUES (0, 0, 'all', 1, 0, 0);

Yeah Drupal community! Yet another great reason to love Drupal.

In this case your are going to set the frontpage configuration. Near the bottom of your settings.php file is a section that is commented our by default for overriding configuration settings. Just add the following code below and change ‘node/1′ to whatever node you want for your new frontpage.

$conf = array ( ’site_frontpage’ => ‘node/1′,);

One big thing not to forget is the comma after the last setting statement.

We ran into this the other day helping somone on #drupal-support irc who had a multisite Drupal setup with subdirectories. He had removed the panels module and the site went belly up.

Blessings