Context Assumptions: a) In our system, all points are considered equal and valid for using as store credit, regardless of category. b) the majority of sites using multiple point categories share assumption 'a'.

In the uc_sc_userpoints.module file, function uc_sc_userpoints_handler, case "user_total", it returns the value from calling userpoints_get_current_points($uid). Called like this, the userpoints api will always return the points for the current user that match the default point category only. If there are any other points from any other categories, they are not counted. The module description states that it will integrate with UserPoints, but nothing about categories. I'd like suggest that it would be more intuitive if the userpoints integration default to using ALL points, as it took some time to pinpoint why there was a discrepancy between point value on user's point page, and available credit on checkout process.

From the userpoints api documentation, the second parameter, tid, is for the id of the userpoints category, and the default value is null, which corresponds to the default user points category. If the value is passed as "all", then all points are given.

Solution:

Change line 34 in uc_sc_userpoints.module from:

    return userpoints_get_current_points($uid);

to:

    return userpoints_get_current_points($uid, "all");

Comments

rszrama’s picture

Status: Active » Fixed

Alrighty, I'll implement the quick fix of specifying 'all' and update the docs for the User Points API. : D

Ultimately, it would probably be best to let people specify which category to use when calculating the user's total store credit, but this should cover a majority of use cases. I'll put this in the 5.x-1.1 and 6.x-1.0.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

tylerwalts’s picture

Thanks!