no longer works with userpoints

The fix should be in vote up/down.

You can easily do it by changing:
userpoints_userpoints($points, $uid, 'Vote up/down points');

To this:
userpoints_userpointsapi('points', $points, $uid, 'vote_up_down');

If this works, please submit a patch to this issue.

I will add support for Userpoints 4.7.x-2.0 when I get back from my travles in a couple of weeks. I will proberbly update to the version of userpoints on my own site.

sorry.. i had posted duplicate... but changed title here (sorry Ron) since original wasn't very easy to find.

my original was at : http://drupal.org/node/118951

and my suggested answer was:

userpoints_userpointsapi('points', $points, $uid, NULL, 'Vote up/down points'); 

although Khalid would know better... but this raises a question

Are either the "event" or "description" stored anywhere? If so, where? - since i don't see it in userpoints table.

I thought perhaps description was a note to store what module raised the points - which is why i suggested the change as i have it so that it matches frjo's original. But now i don't see where either of these are stored. Would this not be an important thing to save?

cheers ,

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

For userpoints 2.0, you should not ignore the event. The description, you can do so, but the event
has to be a "type" of sorts.

Both the event and description are stored in the userpoints_txn table for each transaction.

This allows things like: how many points were awarded by event type?

I wish (in a future version?) to make events a numeric identifier, and modules would "register" the event with user points first, as this makes it more structured, but that will have to wait.

Look into userpoints_basic.module for examples on what events are used for commonly performed operations.

ok.. too funny.. it had just dawned on me that we don't save individual transactions so there is no need to save event and description... and i came back this post to correct my blunder..

but now i see.. obviously there is the txn table that does just that.. cool.

so again.. i think likely my correction for the vote up/down is "more correct" than the one you suggested???

and i now need to go back to my client and tell them they can do what they were looking for since we do keep individual txn's.

not sure if you have stumbled upon my shared_points module i just posted last night but in that i have a userpoints hook to handle points getting assigned by other modules.. and then i call the userpointsapi to assign points.. this of course would put me into an infinite loop - to get out of this i set $event and check it on the way in - if even tis actually sued for something.. perhaps this is a bad idea???

Hi Peter

You should not use NULL in the event, as it identifies the type of transaction, and could be useful in many cases. A NULL here means "we don't know who created this". I don't advocate NULL at all here.

As for your other question, you are right. Your module defines the event ID (normally, your module name), and checks the $event. Bypassing the logic if it is your module is a perfectly valid solution.

good to see my module implementation made sense.

as for the vote up/down module.. i will change my mod as per your comments that i should fill in event as "vote up/down"... and i don't usually like to touch other module code since changes will get wiped on next update... but since i need to make this change anyway.. i will likely also mod vote up/down to do admin settings the way you do it with your modules (and i have been doing with mine) that create collapsed fieldsets.

also, i was disappointed to see that voting.module doesnt integrate with userpoints - i think i saw you have a nodevote module which sounds similar, although from the sounds of it not as advanced as the voting module... but with your api.. easy enough to add userpoints integration even outside of the voting module itself.

cheers,

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

ok, i sort of think that the vote up/down guy might not quite understand hooks... since he calls the userpoints hook within his own code - which i don't think is correct (he should just be calling the api).

but rather than re-write that part i just did integration for userpoints 2.0 and did the admin settings with the hook... and cleaned up a few redundant things (like you really don't need to check inside a hook if the module for the hook exists... since hook won't get called if it doesn't.

anyway... tested quickly and seems to work.. and i will also post under that module as well (even though i am always getting in trouble here for x-posting... blah blah blah...

peter...

oops.. this is the vote up/down queue.. thought it was userpoints for some reason.

sorry about the dig on using hooks...

Thanks for the bug report and the patch. I have committed a modified version of ptalindstrom solution to 4.7.x-1.x-dev. It seems to work as it should on my test site. Please try it out and report back here.

What about the HEAD version? It doesn't seem to be working with userpoints now.

See http://drupal.org/node/125152

Thanks, frjo. For now, I've manually inserted a line that calls userpoints_userpointsapi into vote_up_down.module whenever a vote is cast so the node or comment's author gets the same points. The problem is, it adds (or subtracts) a point while vote_up_down changes the vote record. So, if I give a node +1 then give it -1 vote_up_down will have it rated -1, but userpoints will have its author rated 0. Any ideas about fixing this?