Point Categories

Pools/Buckets/Categories, ya its all the same thing. Yes it would require a small API change especially to userpoints_userpointsapi() by adding a category/bucket/pool setting to it (i.e. $bucket="") . In that function we can add a default setting to be "main".

However all of the queries would then needed to be modified to display the points correctly.

Like I said I'm willing to do the work on this and submit a patch. My work would be on 4.7 though as that is our current environment.

Whoops.. submitted too soon. I'll do a quick writeup on how I envision it working. Need to dig in a little deeper into the API and the code first though.

Heres a quick list of what I think would need to be done.

1) Add a column to userpoints_txn called category
Type: varchar length 30?
--Could be as small as 10, 255 if we want to allow for super flexibility but we're wasting space

2) Change
userpointsapi('points', $points, $uid, $event, $description)
to
userpointsapi('points', $points, $uid, $event, $description, $category='main')

and add code to insert the category in the SQL statement

3) Change
hook_userpoints($op, $points, $uid, $event)
to
hook_userpoints($op, $points, $uid, $event, $category)

4) Change
userpoints_get_current_points($uid)
to
userpoints_get_current_points($uid, $category='main')

obviously we can change the default category and I'll have to write some code to modify the moderation queue queries and all of the returns (for example, the User points display on the account) but in general it shouldn't take long.

What do you think?

At first glance I don't think this would screw up any of the other modules since this is only an API change and we can easily set a default if not passed in. I haven't dug into the other pieces though.

Thoughts/Suggestions?

After talking with Kbahey (thanks by the way) there are the two approaches we see for implementing point categories.
Please comment on them so that we contribute to the whole community.

In either approach we would add a single field to the tables userpoints_txn and userpoints.

What this field is and hold, is the question.

Suggestion 1) The field is an INT which holds a Term ID. If the variable is NULL then all the points wind up in the same category (NULL is a catch all category). The term ID (tid) would come from a vocabulary that the user would choose when enabling the module.

• Pros
• category creation/maintenance is done by the core modules
• Since the DB field is INT performance would be good
• Category names can change without affecting data integrity
• Cons
• Modules couldn't simply add an arbitrary category (like the node table)
• Modules would have to be configured somehow to discover the appropriate TID to use when adding to a category. This would most like happen through an API call to get the Vocab ID, then a module specific USER based setting to set the TID

In this model an API call, userpoints_get_vid(), would return the vocabulary ID so that contributed modules would know which vocab to use. Those other modules could get present a list of terms to the user for term selection or use some other ingenius method for adding the terms (possibly just adding the term into the vocab directly?)

Suggestion 2) The field is an VARCHAR which holds a category name. This would be similar to the node table for node types (varchar 32)

• Pros
• Modules can simply add an arbitrary category (similar to the node table)
• User administration is simplified as the user doesn't have to select the taxonomy term to use
• Cons
• Category names cannot change without affecting data integrity
• Since the DB field is VARCHAR performance wouldn't be as good as in suggestion 1 (Kbahley suggested 6x less performance; which is HUGE)
• category creation/maintenance is done by the Core and Contributed modules

Point categories have been implemented in version 3.x via the use of taxonomy. Please follow this thread for more information.
http://drupal.org/node/153626