SQL error

Sounds like either user_relationship_node_access or workflow is not rewriting SQL correctly, as the patch references removes db_rewrite_sql()... It would help if you tried original code and alternatively disabled either of both modules, to see when the error goes away.

I found the same bug, and I was disabling one by one the modules that have some access realm in the sql error.

After that, I was reading the Drupal API documentation, http://api.drupal.org/api/function/db_rewrite_sql/6.

And I don't see any need to check any right when accessing to the content_complete, as there is no any primary key associated between this content_complete table and any node id, as come by default in the db_rewrite_sql the primary key:

db_rewrite_sql($query, $primary_table = 'n', $primary_field = 'nid', $args = array())

$primary_table Name or alias of the table which has the primary key field for this query. Typical table names would be: {blocks}, {comments}, {forum}, {node}, {menu}, {term_data} or {vocabulary}. However, it is more common to use the the usual table aliases: b, c, f, n, m, t or v.

So IMHO this security check functionally has no meaning as there is no relationship between content_complete and node id's or any existing typical table.

I add a patch for removing the db_rewrite_sql

I guess you're right when it comes to the {content_complete} table. However, when doing queries on node tables I think you should use db_rewrite_sql:

$sql = "SELECT * FROM {node} WHERE type = '%s'";
$result = db_query(db_rewrite_sql($sql), $content_type);

Am I correct? I would like to clarify this before committing any patches.

Of the query the patch changes, only the last two should be corrected.
db_rewrite_sql() is normally used from code that wants to have a list of nodes, users. Using that function allows other modules to add a more restrictive filter on the returned list; that what happened for a Drupal core module that filters out the nodes to which the current user doesn't have access.

I removed db_rewrite_sql from the content_complete tables. Latest version on CVS.

@pvhee: a module can call db_rewrite_sql() for its own database tables too; it has sense to do so if there is a module that can modify the SQL queries made from that module.

Whoops; this is called concurrent editing.
The issue should then be considered fixed.

Testing again.

With Content Profile, and Content Complete configured using the APK's uprofile content type.

With a registered user with standard permissions, (not admin, but can create content profile).

If the user has or not content profile created (never has completed any field in the form) in both cases then I have the ugly sql error in line 223.

If I remove the db_rewrite from this line then the error vanish, working everything fine, if there is no any content profile then there is no errors and no completion bar, but if there is a content complete it shows the progression bar, so good.

So there was something wrong in the db_rewrite_sql to line 223

Reading http://drupal.org/node/324070#comment-1073102, I realize that the problem is not using a distinct selection and that is needed FROM {node} n, when using db_rewrite_sql(), so just changing the $sql statements in the three queries using db_rewrite_sql (), everything works great, with no errors and with security validation.

Thanks, this might solve the problem indeed. I slightly modified the patch to select node id's only (as thats the only thing we need).

Can you check if the patch solves the problem? If so I will commit it to CVS.

It works great, you also solved the other question regarding not to do "select * from", because possible performance problems.

Patch committed. Thanks!