Allow multiple votes per user per target

This seems "by design" of fivestar (allow just 1 vote per user per node). The CCK field saves the vote value. So your history of votes is in the nodecomment trail. But the submission of a new nodecomment deletes the users previous votes with respect to votingAPI. So no overall tally.

See multi axis documentation http://drupal.org/node/457886. I think there is not much difference between nodecomment or Review for that matter.

The problem is twofold imho
1. fivestar_field should not delete all user votes but only it's own node(comment) related vote
2. votingAPI should help with averages ... see ie #561424: Are we really not going to get a fully functional multi-axis rating system in fivestar?

I'm in of need and working on a patch for Product - multiple Review solution but are struggling with function _fivestar_cast_vote($type, $cid, $value, $tag = NULL, $uid = NULL, $skip_validation = FALSE, $vote_id=null) in which criteria are mixed with voting data :(

Please checkout my work so far.

I changed the default value of vote_id to 0. And when creating a new 'review' node set vote_id=-1

It now to work as intended but I ran into a bug(?) when changing the target to another node: The old votes are not deleted.

The checkbox added to the fivestar field is imho obsolete. This field always should be a multiple vote type.

Please review this patch :)

The patch is for 6.x-1.19

You still have to follow http://drupal.org/node/457886 for displaying the widgets

I don't exactly understand the issue here. If you want multiple votes per target, it's limitation of VotingAPI, not Fivestar: storage of 1 vote per user per target.
If you want to store votes for multiple targets in single CCK field, that would be feature request, though I don't see any sense in it.

Also, I suggest not using term "node" here. It's not descriptive enough. You should use either "review node" or "target node" to distinguish between node containing (or, better word would be casting) a vote and target node to vote for.

With 'review nodes' I mean CCK content type with fivestar_field, nodecomment, ...

@crea

What I learned from creating this patch is that it's a bug within Fivestar. Why's that? Because the patch is only about Fivestar. So please review it :)

The patch regarding CCK fivestar_field adds a vote_id to remember next time the 'review node' is changed to only change that particular vote_id record.

The current fivestar behaviour is _delete all user votes_ refering the target node/user/axis combo which is weird behaviour because when creating two 'review nodes' on the same 'target node' the older 'review node' holds/display my old rating while the votingapi_votes table only hold my latest vote.

Hope this explains better what this issue is about.

As far as I understand you should build your workflow so a user only allowed 1 review per target node. What is your use case that requires multiple reviews per node from same user ? It simply doesn't make sense: that's what axis for.
When you have 2 review nodes, it's race condition (kind of): upon save they will recast their votes and overwrite each other. So it's broken workflow.
Yes, fivestar will still display old vote, even it was already overwritten, but I still think it's not bug. This is simply lack of feature , lack of fixing broken workflows. Do you want to support broken workflows in Fivestar ? Or am I misunderstanding you ?

Also, I think passing vote_id to VotingAPI is hack (improper use of API). Actually you should first get answer from a VotingAPI developer in #551852: VotingAPI overwrites old values before coming up with such hack in Fivestar.

Use Cases:
- Visit a restaurant every month and rate it on every visit.
- Rate a service on each interaction i.e. Performance of drupal.org
- Rate content 'on behalf of'

@crea
You are missing the point ... this patch is functional without modifying votingapi _and_ the call to votingapi contains too few filtering which leads to deleted old votes.

function _fivestar_cast_vote($type, $cid, $value, $tag = NULL, $uid = NULL, $skip_validation = FALSE) {
...
       votingapi_set_votes($votes, $user_votes);

In my opinion this is a huge bug with fivestar_field ... it's possible to _create_ multiple review nodes so it _should_ be possible to rate multiple times.

Hope this made sense.

Well, your usecase is complicated enough: you will need also custom tallying function, because simply averaging votes in your scenario wouldn't work (unless you want to give users with more reviews louder voice). But it makes sense for you.

Anyway, the patch has code style problems - no spaces before and after operators, e.g. "$criteria+=$user_criteria;".

As far as I remember, allowing only one vote per user per target was "by design" of fivestar, so I'm marking this feature request.

Related 5.x issue that was never finished: #215799: Multiple votes for logged in users

I have a use case they may or may not be applicable to this issue. I am trying to decide whether to use fivestar for the following:

- Rank various reoccurring events by number of people attending them.
- In this instance the number of people going to it are not as relevant as the number of people that have historically gone to it (e.g., it may have 5 people going, and every other event only has 4, but historically there are 20 people attending).
- Intent was use to use a Voting API calculation hook to create a new calculation that divides the total vote for the day by the maximum of the previous 5 days of votes.
- It sounds as though the deletion of historical votes would restrict my ability to make this possible.

After reading the discussion crea referenced it sounds as though because Voting API does not have this functionality, Fivestar doesn't have as well. Would this be accurate?

I have another use case. I'm working on a site where users can sell products to other users. The users are given the ability to rate other user's (content profile) pages. Since multiple transactions may go on between users, doesn't it make sense that each transaction will add to their vote rather than change it?

On a related note, isn't this almost the same as the "Anonymous vote rollover" feature in the voting api module? This is essentially the same functionality (allow multiple votes from a given ip within a given timeframe), except we want to give that ability to authenticated users too.

I think the data model / presumptions need to change in the use cases above, likely via nodereferences.

I begin with the presumption that 5star/votingAPI relies on a "one-vote-per-node" persumption, similar to the adage that "a node is a node is a node."

This means that the node is a fundamental unit of both data storage, and a fundamental conceptual unit.

In order to change the Voting API to allow multiple votes per node, for instance, you would need to extend the db tables. It would likely prove difficult to do this in a manner that covered a large, generic series of use cases.

The natural way to extend is the node structure itself. In the above @#16, transactions should surely be nodes, and transactions should be rated by the people who carried them out. And then you can sum those ratings as you choose.

Similarly, if you have multiple VISITS to a restaurant, then the natural place to record those visits is a NODE. And so on.

Does that make sense?

@#17

This issue is about casting votes ... that is on another node / user / comment / thingy ... which is a reference

I rate my visit on date x to this restaurant y with a vote v is likely to be implemented with content types Visit and Restaurant.

Crea is right in that people visiting a restaurant more often do have a louder voice.

But the point here I think is Fivestar deletes old casted votes. And for this multiple to happen these lines are key.

         if (is_numeric($items[$delta]['target'])) {
-          _fivestar_cast_vote('node', $items[$delta]['target'], $rating, $field['axis'], $node->uid, FALSE, TRUE);
+          $multiple = $field['multiple_votes'];
+          $vote_id = $multiple ? ($item['vote_id'] ? $item['vote_id'] : -1) : 0;
+          // TODO: we need to delete the votes for the old target
+          $result = _fivestar_cast_vote('node', $items[$delta]['target'], $rating, $field['axis'], $node->uid, FALSE, $vote_id);
+          $items[$delta]['vote_id'] = $multiple ? $result['vote_id'] : null;
           votingapi_recalculate_results('node', $items[$delta]['target']);
         }

VotingAPI is capable of handling such data and is capable to handover the calculation to custom coding needs too.

Hope this helps. (Unfortunately my customer is still struggling with the _needs_ of this feature)

Subscribing

I am working on a similar site. Users rate consultants (profile nodes) via a review node. Since users many times hire the consultant more than once on different projects; thus the need to allow the user to cast more than one vote. Much like the restaurant scenario. Subscribing.

Subscribe

I must confirm that the patch from comment #3 (http://drupal.org/node/561622#comment-2427030) worked fine for me. I can have multiple votes per user per target.
Furthermore, if you get a warning message like this:

user warning: Column 'field_YOUR-FIELD-NAME_vote_id' cannot be null query: 
INSERT INTO content_type_CONTENT-TYPE (...) VALUES (...)
in /PATH-OF-SITE/sites/all/modules/cck/content.module on line 1213.

you can use phpMyAdmin to edit manually the fields for each column (field_YOUR-FIELD-NAME_vote_id) of your content_type_CONTENT-TYPE. Click to check mark the box labeled "NULL". Do not change the default values.

Subscribing

As @TheodorosPloumis stated on #22, you can edit the fields manually or you can patch fivestar_field.inc with:

'vote_id' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => FALSE),

instead of:

'vote_id' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE),

This line is found in function fivestar_field_settings as the last line in the 'database columns' case.

After this change, when you check and save the "Allow multiple votes on target" box per CCK fivestar field you should not get the warning message.

Should this be finished for 7.x and then backported?

Is this even an issue in the d7 branch? I don't believe so.

subscribing.

Hi,

is this patch (http://drupal.org/node/561622#comment-2427030) going to be a part of this module? Do you need to test it? I would be happy to, what I dont want is that I would lose the patch with the next module update.

Thanks a lot,
Petiar.

I have the latest dev version of 7 installed and see no way, or setting that allows multiple votes. It is quite interesting that anonymous users [per voting api] can cast multiple votes but not authenticated users, or am I missing something?

Great module!

To enable multiple votes by authenticated users i just edited the votingapi.module (/sites/all/modules/votingapi/votingapi.module)

From Line 132 to Line 153 added " // " infront of all codes which disables clearing out old votes if they exist and therefore members can cast multiple votes

this is how it looks after i add " // "

// Handle clearing out old votes if they exist.
  //if (!isset($criteria)) {
    // If the calling function didn't explicitly set criteria for vote deletion,
    // build up the delete queries here.
    //foreach ($votes as $vote) {
      //$tmp = votingapi_current_user_identifier();
      //$tmp += $vote;
      //if (isset($tmp['value'])) {
        //unset($tmp['value']);
      //}
      //votingapi_delete_votes(votingapi_select_votes($tmp));
    //}
  //}
  //elseif (is_array($criteria)) {
    // The calling function passed in an explicit set of delete filters.
    //if (!empty($criteria['entity_id'])) {
      //$criteria = array($criteria);
    //}
    //foreach ($criteria as $c) {
      //votingapi_delete_votes(votingapi_select_votes($c));
    //}
  //}

Can this be done without hacking core of the votingapi module? I like this but I'm afraid I would forget it's hacked when time to upgrade. Any suggestions?

#30 works excellent.....thank you! I wonder if they can put this in core?

Code in 30 does NOT WORK if you delete the comment or whatever is was you posted the fivestar vote on. See this explanaton

http://drupal.org/node/1337426#comment-5250944

I deleted it and it wiped out any star average.

I created a patch for D7 which allows multiple votes per user per target. I'm not sure about this issue as it is a D6 one. Shall I bump the version to 7.x and post my patch?

@Ronino: please do so :)

Looking @ http://drupal.org/project/usage/fivestar you definitely should bump this to D7

Looking @ http://drupal.org/node/103123/commits most commits are D7 but the project seems silent for more then 7 month.

Ronino, please post

Has there been any progress on this for D7? With out thinking about it I set up my site and ran into this issue :P . I need users to vote several times on the same product and have it calculated as an average since the customers re purchase the product as there will be different batches of the product. I think this is a more common requirement for review sites than is stated here.

I tested out the voteapi module hack and it does work but as stated any change to the node that has the vote field the average gets wiped out for the entire field/target so its useless.

I'll do a $100 bounty to get this sorted out.

I started a paid service request here https://drupal.org/node/2269679

Here's my go at it. This patch will apply to 7.x-2.x-dev, but it will also apply to the 2.1 release, and I suggest just using that because the latest dev code seems to be broken in other ways.

With this patch, the Voting API "rollover" settings will be respected when it comes to interpreting a possible duplicate vote, so go to Administration > Configuration > Search and metadata > Voting API and set those values as desired for anon and authenticated users, if you haven't already. Then apply this patch and watch the duplicate votes roll in.

Thanks I'll test it later today.

Test this one instead - the previous patch wasn't properly handling cases where the rollover time is set to "Never." Also, I think the previous patch was against the wrong branch - master instead of 7.x-2.x. Not sure if that's why it failed to apply according to testbot, but…

The last submitted patch, 42: 561622-42-fivestar-multiple-votes.patch, failed testing.

Indeed it did, because as I said in #39, the HEAD of Fivestar seems to be broken in other ways currently - I bet the tests don't pass *without* this patch either. Apply it to the 2.1 release instead and do your own testing.

I think something was wrong with the testbot / low-level tests at that time.

Anyway, I'd like to point out an alternative patch at #2326775: Establish tie between a vote and its rating-while-editing source field which seems to fix more things. (This issue is about the first of 2 bullet points mentioned in issue #2326775.)

@end user: re "any change to the node that has the vote field the average gets wiped out for the entire field/target"... I didn't test this yet, but #2326775 should prevent this. It should leave votes on the source nodes/comments alone... but only votes cast after the patch in #2326775 is applied. For votes cast earlier, Fivestar simply cannot see whether the vote is cast via the target node or another source node. Your only option to prevent deletion of older votes, is to set rollover to "Immediate" at /admin/config/search/votingapi.

[ edit: removed comment about the patch in this issue, which is fine. ]

*cough* disregard the above comment for now, please. The patch in #2326775 is not correct.

If it is corrected, it will probably fix the "any change to the node that has the vote field the average gets wiped out for the entire field/target". But it will likely not fix this issue; these things are separate.

I'll test the patch in #42 when I have my head screwed on straight again.

For anyone who comes to this issue the problem described can be in 99 percent of cases solved by going to /admin/config/search/votingapi and changing the value of Registered user vote rollover setting