Profile never updated

I ran into the same issue and saw that the userpoints_user function case 'view' is calling userpoints_get_current_points without passing in a value for the '$tid' argument. Because of this, the user_points_get_current_points defaults to using the 'Uncategorized' category. I was able to correct the situation by modifing userpoints_user as by adding 'all' as the $tid parameter.

 case 'view':
      // Get the points for the user
      $points = userpoints_get_current_points($account->uid,'all');

The question I have is shouldn't the default in user_points_get_current_points if no category is defined be to use the 'all' model instead of the 'Uncategorized' category?

A patch went in today for 6.x that adds 'all' to hook_user. See here for details http://drupal.org/node/252504

If someone can check this, and create a tested and working 5.x back port, I will include it.

This has been discussed before and the answer is that user_points_get_current_points should not default to the all category but rather have an ability to sum the points if necessary.

In that past (and maybe this is changing) users have used userpoints to segregate points vs. merely classifying them.

aaah... this patch completely negates an early decision we made and we should really come to a consensus on this.

The patch default the user's profile page to display "all" points; which sums all the points.

Earlier we decided that the summing of points was a contrib module BECAUSE the categorization system was meant to segregate points vs. classify them.

I know of several websites where this patch is going to be a pain for them because they do not want the "All" shown and, maybe more importantly, this is going to destroy their legacy view when they upgrade (i.e. if they were using points to segregate then all of a sudden they are munged together).

I think we need to roll this patch back and discuss the SUMing of points are part of the system; Specially do we
1) SUM all default options from various function calls
2) Display SUMs of all category whenever displaying only a single point value.

again this patch made the module itself inconsistent across its user interface as know where else do we display a SUM of the points.

additionally. the patch should be rerolled to move the userpoints_get_current_point after the permissions check to prevent an unnecessary DB call if the user's doesn't have the permission to view the result.

I guess we need to do either of the following:

1. Document the fact so we don't get these support requests.

2. Have a settings for it that can be toggled (sum of all points, or just uncategorized, or something like that). This way sites can have it which ever way they want.

Here is another variation of that http://drupal.org/node/252847

I guess it is confusing ... so we need to clarify this, or provide options so the end user can display it whichever.

Sorry, I wasn't aware of this issue, nor the earlier decision on this when submitting the patch. I was simply working on upgrading 5.x-3.5 hook_user() to be compatible with 6.x. And yes, it confused me, when seeing the points shown were not the sum of all categories. There are cases where a sum is needed, and there are cases not. I'd suggest leave this to a contrib or site-specific module to decide, i.e. remove this piece of hook_user() code completely from both 5.x-3 and 6.x version. What do you think?

The issue in http://drupal.org/node/252847 looks to be a bug to me. If the filters says 'Display all', then it means all points from all categories to me.

Dami

Please submit a patch in the other issue to make D6 consistent with D5 (uncategorized points shown).

Then, we decide whether we just document it or provide a settings with several options (uncategorized, sum, or specific categories).

I am leaning towards the options route, but would like to here what others think.

I think providing a way for users/admins to select whether to show a particular category, the default category or all would be a good compromise. I just don't think defaulting to "all" would be good.

no worries Dami you did good work is just that categories and being used in an unexpected ways and we just need to figure how best to handle all cases.

OK, I will submit a patch to change it back to use 'uncategorized' as default.

If using setting options is the consensus, I will see if I can come up with some code as a first step.

Since it has been proven that it is confusing to do "uncategorized" vs. the "sum" that some think it should be, I would say that doing the option thing, with default to uncategorized would be the best way forward.

jredding agrees with me on this, so go ahead and do a patch on this basis.

ya I'm with ya all on this. I think both methods make sense in different applications and although this is an easy change to do with a tiny bit of coding a lot of people using these modules aren't developers so a quick setting dropdown and an if/then would make people's life a lot easier ;)

I'd also suggest that this would fall in line with my reasoning on wanting to separate the API from the administrative interface as this, now feature request, is classified incorrectly. The userpoints.module currently controls this setting (I changed it to reflect correctly).
http://groups.drupal.org/node/10539

Wanted to bump the issue, I'm running 5.x-3.7

Sorry for spamming the participants in this issue. Due to the release of Drupal 7 and the lack of time from the maintainers, I'm closing all remaining 5.x issues for Userpoints.

Feel free to re-open this issue or create a new one for 6.x or even better 7.x if this bug is still open or feature is missing for these versions.