There are a lot of changes that we have in store for userpoints and we are planning to get them all in before we release an official stable 6 version of UP. I, however, got a nice whipping when I released version 5.3 and I do not want a repeat of that. 5.3 was released with several tiny, stupid bugs that could have been easily avoided if I had the time to test the module properly. Unfortunately I nor anyone else had this time. Fortunately we have a new weapon. Simpletest.
I have already begun writing several tests of Userpoints and I'll be checking them off this list as I complete them. I'd like to get all of these in before any major work to the API is performed as it is currently stable and I'd like to keep it that way. My lists of tests is below, please free to add to them and, better yet, write a test.
It looks daunting but many of these tests are only a few lines and a few of them are a single line.
API tests
- Points
Call with only points are granted to logged in userCall with points matches transaction tableCall with points matches transaction & updates summary tableNegative points caused summary table to decreaseTransaction table and cache table stays in sync through multiple point add/deletes- Points Array
Call with no points failsCall with non numeric point values failCall with only points are granted to logged in userCall with uid & points are granted to the appropriate userCall with uid & points for a non-existent user failsCall with a tid that is non-existent failsCall with points & description, description is set correctlyCall with points & event, event is set correctlyCall with points & reference, reference is set correctlyPoints in transaction table match points in summary table- All
Summary tables sums to non-moderated points in transaction table- userpoints_get_current_points
Called with no arguments returns current userCalled with uid returns points for default tid- userpoints_get_max_points
Called with no arguments returns current userReturns same number as highest point level according to transaction table- userpoints_get_default_expiry_date
Returns a valid unix timestamp- Moderation
- Call with invalid moderation status fails
- Call with points & moderation and set to moderation correctly
- Call with points & moderation does not modify summary table
UI and API tests
- userpoints_get_default_expiry_date
- Returns a valid unix timestamp
- userpoints_get_categories
returns an array- userpoints_get_default_tid
- returns a valid term id
- userpoints_get_default_vid
- returns a valid vocabulary id
- Expiration
- Points added with an invalid expirydate (non-timestamp) fails
- Expirydate given via API matches transaction table
- Points expire correctly (add points to expire in 1 sec. then call expiration
- Correcting entry is added to transaction table & summary table is updated
- Permissions
- User without admin userpoints permissions can not modify points
- User with admin userpoints permissions can modify points

Comments
Just a "woot, woot" on tests
When writing the tests I found a bug in the core API wherein the user'd ID was not being properly tested thus it was possible to give points to non-existent users.
The bug has been fixed and committed to the DRUPAL-6--1 branch.
-Jacob Redding
-Jacob Redding
Another possible bug
During testing it became clear that the expiration date will accept any positive number. This allows someone to grant points on Feb 18th, 2008 but have them experience on Feb 18th, 1980.
I can see instance where this is allowed and I don't see this as a major bug as these points will be immediately expired at the next cron run. I wanted to post it and get some feedback on it though.
-Jacob Redding
-Jacob Redding
Not really a bug
I am not yet a user for Userpoints, kind of waiting for 6.0 ;-)
So I can just comment from my plans. For me this immediate-post-expiry constellation would NOT be a bug as this could automatically avoid an award for an outdated task. Absent some very detailed dealing with this problem it seems a smooth universal solution. It may be good to echo a warning to the user, though.
-Rex
cool, thanks
The UI does provide this warning, this "bug" is only allowed through use of the API (i.e with code).
Thanks for the feedback it is much appreciated.
-Jacob Redding
-Jacob Redding
'Users by points' page gives error
I have Drupal 6.14 and Userpoints 6.x-1.1 . Whenever I try to load the users by points page, I get a blank page and on going back, the following warning is displayed:
warning: Parameter 1 to theme_userpoints_list_users_row() expected to be a reference, value given in /srv/http/amit/includes/theme.inc on line 617.
-Anuj
Do you have PHP 5.3? I had
Do you have PHP 5.3?
I had the same problem but after editing userpoints.module I got it working.
I removed the ampersand (&) before the dollar sign ($) on variable names for example I changed it
From this:
&$form_stateTo this
$form_stateI did that with all variable names and it seemed to resloved the issue.
As far as I know this breaks compatibility with PHP 4 so be careful you backup any files before you change them in case you need to go back.
Got the same problem but you
Got the same problem but your solution didn't helped me. Website is still in process of dev and testing so it runs localy using xampplite.
how to deal with this?
I got sick of all the PHP 5.3
I got sick of all the PHP 5.3 problems so I recompiled PHP and reverted back to PHP 5.2.12.
Life is much easier now at least with regards ro Drupal 6 module compatibility.
If that doesn't work I don't really know what it could be on your site.