New submit error, non-admin user, postgresql database

I missed this during my patch process for 4.6 =\

It's all due to the fact that I use the admin account to test, and it seems this occurred because the node permission form isn't present for normal users.

This should go into the next release ASAP, since this is a show stopper bug.

Following the patch provided by szimszon, I've found these are required to work with creating forum content.

Yes, very critical. Thanks for the fix. Drupal 4.6.X is not very useful to PostgreSQL users without node.module_7.patch. (I ran into the problem using the flexinode module, but obviously it affects a lot of things). Is there some way for PostgreSQL users to be plugged into the testing process?

Hiya!
I rewrote node.module week ago, but wasnt sure if only these two values can be null?

+ $node->sticky = ($node->sticky) ? $node->sticky : 0;
+ $node->moderate = ($node->moderate) ? $node->moderate : 0;

Instead of that I checked all values, and set them to 0, because i think I had some problems with other null values with image.module. Now when I create a image, if I dont write any descripction "0" is shown as description :) Hey, at least there isn't any error :)

    // Set some required fields:
    $node->changed = time();

    // Prepare the query:
    foreach ($node as $key => $value) {
      if (in_array($key, $fields)) {
        $q[] = db_escape_string($key) ." = '%s'";
        $v[]= ($value==false) ? '0' : $value;
      }
    }

The same thing had to be done on update node and insert node I think.

To got things going for me I had to rewrite $cond synthax, also in similar way.

   // Turn the conditions into a query.
   foreach ($conditions as $key => $value) {
-    $cond[] = 'n.'. db_escape_string($key) ." = '". db_escape_string($value) ."'";
+    $cond[]=($value=='') ? 'n.'. db_escape_string($key) ." = '0'" : 'n.'. db_escape_string($key) ." = '". db_escape_string($value) ."'";
   }

So now I just have to filter values like descripction, so that 0 dont come when no content is entered.

Again, are you sure that only sticky and moderate have to be changed, because there are lots of integer values in node table.

Here is my node.module.diff to 4.6.1 !

Cheers

Ooops, didnt see upper diff file, I see that other values are changed also :)

Is there some way for PostgreSQL users to be plugged into the testing process?

It's hard. I'm running Drupal with postgres, and while minor pgsql bugs like missing colums from GROUP BY clauses and such are frequent, it happens all too often that I just quickly fix them, and postpone reporting until I forget it; especially if they're in non-core modules, whose pgsql support is often poorly maintained. But regarding to minor SQL errors: 4.6.x is actually much better than 4.5. This bug was an exception, but when I first realised it, the fix was already here. This is also problem: how much time I should waste after fixing easy bugs to check, if it was a dupe? Is it better to fill dupes than leave unreported?

Well, there is another pgsql bug in node module, that I so far have not reported. See attached patch, which is against 4.6.0 and includes both node.module_7.patch and my fix. Typical Drupal pgsql bug: some bad SQL, quick and easy to fix. Don't know whether it's a bug or not, and don't remember what triggered it.

It can also be really hard to report bugs if your system uses rare patches. See here. I'd really, really, like to see that bug fixed, but no one who would have the necessary knowledge seems to be interested. As none of the core modules trigger it, not every pgsql user sees it, and I did not dare to mark it as critical either.

And as I'm not PHP guru, It was really hard to track down. It already was in 4.5.x, but I did not understand it at all. Only when it occured in 4.6. with two totally different modules (event and sitemenu), I understood that the problem is probably in core. But as the problem is taxonomy.module -related, and my taxonomy.module is patched with two different patches (i18n and taxonomy_access), it is hard to give any good suggestions in bug reports. It is also hard to say what all could trigger this. I only know that something is wrong; something that can create nasty surprises for PostgreSQL users.

totally agree with you! Had same issues as you did. And I would add image.module, when counting numbers of pictures in image galleries. It is something wrong with taxonomy, or taxonomy_access modul. Currently on my site, TA is disabled and everything works OK. But i really need TA access module, and would like to see this issue solved.

Setting status to patch (code needs review).

Does this need attention for 4.7?

Marking as duplicate of http://drupal.org/node/28996

Thanks for your work.

Thanks for the work everyone above did on this issue; I'm having the same problem. The latest patch posted by plj successfully compensates for the missing Options form when a user doesn't have the Administer Nodes permission, by filling in the missing Options values when creating a node, except that it doesn't add a default value for "status" if the "Publish" option is disabled by default in the content config. The site I'm setting up doesn't allow publishers to submit Page or Story content as "Published," so I have this Option disabled by default for these content types.

Looking at the code in the patch, I see that the following defaults have been introduced:

+ $node->sticky = ($node->sticky) ? $node->sticky : 0;
+ $node->promote = ($node->promote) ? $node->promote : 0;
+ $node->moderate = ($node->moderate) ? $node->moderate : 0;

I added this one to compensate for a missing "status" value:

+ $node->status = ($node->status) ? $node->status : 0;

This solved my problem. I also looked into whether another default was required for "revision" but because this value is specifically checked in node.module and assigned a value if not found, it doesn't trigger an SQL error when the "Create Revision" Option is disabled by default in the content config.

I've attached an updated patch that includes the missing "status" value.