Usernodes are created with uid=0, entries in 'usernode' table also have uid=0

I can not reproduce this on my system. Do you run the latest CVS version of the usernode module?
If so, please provide more detailed steps on how to reproduce your issue. If not, please update and test again.

I'm experiencing the same problem on a fresh 5.1 install. Existing users were assigned a usernode when the module was installed, but new users are not added correctly to the usernode table. They all have a UID of 0.

mysql> select * from usernode;
+-----+-----+
| nid | uid |
+-----+-----+
| 6 | 0 |
| 8 | 0 |
| 9 | 0 |
| 4 | 1 |
| 5 | 2 |
+-----+-----+
5 rows in set (0.00 sec)

Looks like the node table is also getting a uid of 0.

mysql> SELECT * FROM `node` where type = 'usernode';
+-----+-----+----------+---------------+-----+--------+------------+------------+---------+---------+----------+--------+
| nid | vid | type     | title         | uid | status | created    | changed    | comment | promote | moderate | sticky |
+-----+-----+----------+---------------+-----+--------+------------+------------+---------+---------+----------+--------+
|   4 |   4 | usernode | Peter         |   1 |      1 | 1170214381 | 1170214381 |       2 |       0 |        0 |      0 |
|   5 |   5 | usernode | ambertronic   |   2 |      1 | 1170214381 | 1170214381 |       2 |       0 |        0 |      0 |
|   6 |   6 | usernode | Dean Blosberg |   0 |      1 | 1170219575 | 1170219575 |       2 |       0 |        0 |      0 |
|   8 |   8 | usernode | TestUser      |   0 |      1 | 1170252597 | 1170252597 |       2 |       0 |        0 |      0 |
|   9 |   9 | usernode | secondtest    |   0 |      1 | 1170253897 | 1170253897 |       2 |       0 |        0 |      0 |
+-----+-----+----------+---------------+-----+--------+------------+------------+---------+---------+----------+--------+
5 rows in set (0.00 sec)

NB: I'm using the LoginToboggan module. I've tried setting the checkbox for "immediate user login" and assigned a pre-authenticated role, with the same results as an ordinary (email-to-validate) account.

I uncommented the workaround that disables the "Your Usernode has been created." message and discovered that it appears just before "Your password and further instructions have been sent to your e-mail address" during account registration. I believe that at this point, the user is still a guest, so the usernode is being created when there is not a user logged in; $user->uid = 0.

Adding a few drupal_set_message() calls in the module reveals the following:

usernode.module:usernode_insert thinks node->uid is 0 
Your Usernode has been created. 
usernode.module:usernode_create_node thinks node->uid is 

So 0 for the first function and "" for the second.

I don't know enough about drupal's hook system to get much further with this, but I think I'm on the right track.

I was unable to get this working, with or without the LoginToboggan module. I'm giving up and using CCK for my application, along with a cron hook to ensure every user has one of the CCK nodes that I've developed. It still would be nice to have usernode working, though.

NB: There's no difference between the latest CVS version and the tarball in the modules page except for the CVS header line.

Oh yeah, that was an interesting problem. (I tried creating the users from the admin interface, which was why I didn't encounter this bug.)

This issue was caused by Usernode 5.x using drupal_execute() for programmatically submitting the usernode forms when creating them. (Usernode 4.7 did this by writing the tables manually, which was not quite as clean.) The point is that drupal_execute() is run with the permissions of the current user.

So while the form was submitted correctly, drupal_execute() simply didn't have the permissions to create a form for "another" user. (Even when registering a new user, you are still not logged in, so the uid of the global $user object is still 0.) Whereas from the admin interface it has to work because you've got the "administer nodes" permission.

The solution is as hacky as compelling ;) ...see the attached patch.

Maybe also change the status of this issue accordingly.

I've just committed the bugfix, so that there is a working version.

However I'd like to see a cleaner fix for this. One approach I can think of:

Change hook_access, so that usernodes may be created by the user as long as he has none. Then drupal_execute() should work and afterwards the user has no permission any more to create another usernode.

I think hook_access() can't do it. The problem is not that the anonymous user can't create those usernodes at all - they are created indeed, only with "anonymous" as owner (it seems that hook_access is bypassed anyways, because $op='create' already returns false, so the anonymous user shouldn't be able to create a usernode anyways, but still does).

node_submit() only allows changing the owner uid (from the 'name' form value) if user_access('administer nodes') returns true. So I can think of the following possibilities to get it done:
- Temporarily log the user in (like the above patch has done) so that created nodes are automatically owned by the right user, without the need of changing the 'name' form field.
- Temporarily get 'administer nodes' access rights for the anonymous user, so that the specified 'name' field is actually respected.
- Change the owner after creating the node, but before writing the {usernode} table row. Which involves remembering the uid somewhere and use hook_submit() to actually set it.

I don't know how to do the second approach, but it doesn't seem less hacky than the current one. So maybe I can find a way to get a solution with the third approach. Thoughts?

ah yep, that's right. solution three sounds to be the best way, but what about this one:

* don't create usernodes on hook_user 'insert' anymore, but on hook_user $op login. then the user should be already logged in (;) and so we should have permission to create the usernode for him, if he hasn't already one. We could use hook_user to autoload the usernode id into the object, so it will be there after login. (otherwise not, because the session system doesn't invoke hook_user when it rebuilds the user object).

perhaps solution three is still better.. ;)

Tada! Let's have a type 3 solution :D

I agree, solution 3 is the best one :)
However I'd love to see some improvements on the patch.

1. I think it would be cleaner if we remove the realuid field and just set $node->user (through a form field of type value) like the module does it, when a node is loaded. Then we could just set the usernode uid from $node->user->uid
2. For backward compatibility we can write back the uid from there on node submit, so that the node author still defaults to the usernode's owner, but please make sure that this is done only for usernodes. (content-type)

Something like this?

yep, thanks. committed :)

sorry to open.. but otherwise i guess no one see this...

AND.. i guess not a big deal since the cck nodes that get added as part of usernode (with regprofile) and the usernode itself is a custom type... but the entries for these nodes that does get entered into the node_revisions table still has uid = 0

that's the task of the registerprofile and has nothing to do with the usernode. so please open an issue there.

subscribing

don't reopen old issues.