VotingAPI resets votes but adds unlimited energy when a user votes multiple times

I think up/down should prevent voting if a user has already voted.

Ditto.

Using Fivestar module as well, a multiple click on a star widget registers only one vote on the node page, but it keeps adding over and over radioactivity database record. This is a critical functionality.

From the perspective of radioactivity we could solve this if a new vote in votingapi were treated as
* Undo current vote
* Do a new vote

I think that change is unlikely to make it into votingapi module :/

So, I guess the code in radioactivity that deals with votingapi should check whether someone has already made this exact vote prior to giving the energy. It's a little trickier to know exactly how to respond when someone changes their fivestar vote from a 5 to a 4 :/ I'm starting to think that the generic radioactivity_votingapi functionality should be removed in favor of functionality that is specific to the widgets so that it can better handle situations like this.

+1 tracking...

#5,

This is problematic since undoing a single vote is impossible. If I have given an energy of 5 to a node yesterday, how can I know what the leftover energy for the single addition is today? Well, we could save the vote timestamps and count backwards when deleting (assuming the decay formula has not changed).

An easier fix would be preventing changing your vote after the first cron run after vote (after the energy has started to decay).

Onaz, I think it's OK.

* Yesterday: user votes and node gains 5 points.
* Today: the value of that 5 is now down to 4 (for example).
* Today: User votes again causing: subtraction of 5 points, addition of 5 points. The net effect is zero and the 4 points remain.

Subscribing - this also makes fivestar radioactivity useless

subscribing

Thought I'd poke my head in -- the reason that vote-sets are treated as blind updates has to do more with efficiency than anything else. In previous versions of VotingAPI, every vote had the potential to trigger a full set of CRUD operations. I'm not opposed to it, but it definitely makes it dicier to handle very heavy vote storms.

I don't suppose it would be possible to rely on the recalculation cycle -- I haven't looked at radioactivity's code, but it seems like a bad fit for that operation. Hmmm...

To provide another example:

* Yesterday: user votes 5 and node gains 5.
* Today: the value of that 5 is now down to 4 (for example)
* Today: the user votes a 4, their 5 is decremented by 5 to -1, the 4 adds 4 points so it now is worth 3 which is roughly what it should be worth if the user had voted a 4 yesterday.

I think that's still OK.

@eaton, that makes sense. I see two solutions here: 1. the widgets prevent voting if the user already has voted. That only works for simple vote widgets like up/down. 2. The API lets people know the old value in addition to the new value. Obviously that has performance implications, perhaps it should be a setting that something like radioactivity could require?

For me, adjusting Rules was the solution. I'm using a thumb up/down widget so when someone vote, 1 point is added. If he vote again, I got a rule for a vote delete (checking the vote value) so it does -1 and then the vote +1. If he abuse the thumb down, it does +1 -1...

Issue triage: Closing issue, the 6.x branch is no longer maintained.

If you believe this issue is closed in error, feel free to re-open.