Username does not prepopulate when adding points from user's profile page

I'm not exhibiting this behavior. In fact if a txn_id exists the point can ONLY go back to the same user according to the API moreover in this patch the following code exists

+  if ($txn_id) {
+    $txn_user = user_load(array('uid' => $txn_id));
+  }
   if ($mode == 'edit' && $txn_id) {
     $result = db_query('SELECT * FROM {userpoints_txn} WHERE txn_id = %d', $txn_id);
     $txn = db_fetch_object($result);
     $timestamp = format_date($txn->time_stamp, 'custom', 'Y-m-d H:i O');
-    $txn_user = user_load(array('uid' => $txn->uid));
   }

Which loads a user twice with editing points. If you're adding points the user is loaded but that's because you're adding point thus you do not have a txn_id.

maybe I'm confused.

I can reproduce this on my sites.

1) upgrade to userpoints 5.3
2) log in as admin
3) go to a user's profile page
4) click on their point total
5) the edit page that appears is not populated with their username

With v5.2 the username field was populated (see attached).

hhm.. something between 5.2 and 5.3, I'll have to check my dev environment its probably a version behind.

In either case the patch is wrong as it would potentially load the user twice.

Oh so this is from V2 to v3.. hmm. is userpoints_transactiontools enabled by chance? Its not compatible with version3 and could cause some odd errors.

I thought maybe you were on to something (with your transactiontools idea) jredding. I just checked the 5.3 site and we only have userpoints and userpoints_basic installed/activated.

I'm not saying that you're wrong but there is something else at play here

If the mode is add you should NOT have a txn_id because "add" means that you are granting points to a person, if you are granting points you do not have a txn_id (cart before the horse).

I'm curious as to why when the mode is edit (thus you have a txn_id) on your installs there is not txn_id. I really don't know.

And I don't want to be nitpicky here but for coding reasons if its the mode then it should be an if/else not if {} and a second if {} . They both do the same thing (as $mode can't be both add AND edit) but its easier to read and thus cleaner code to properly distinguish that it has to be add OR edit but never both. The code currently reads as though it could possibly be add and edit (which is impossible).

Thank you for all the work I really appreciate I just want to make sure you squash the correct bug, especially since I can't reproduce this on a fresh install.

wow.. so I'm really confused. The title reads

User name field fails to carry over to edit view

Edit view implies that you are editing existing points. In this bug really about "Adding Points"? and how are you adding these points?

I've observed (in my environments) that when you're on a user's profile page and click a user's point balance, you are taken to a userpoints transaction form. With 5.2 this form was pre-populated and knew who the user was. In 5.3, the form is not pre-populated.

I believe what brownjed is pointing out is that in 5.2 the uid was passed from the profile page and used to build the transaction form. In 5.3 it may be getting passed but it's not being used to build the form (populate the username field).

Just my observation.

Kevin

changing the title to better reflect the error.

I think I finally got it now. I'll take a look at the patch again with this in mind and see if its fixes the right bug.

Thanks again!

fixed and committed