Vote value in choices field multiplies instead of being added

Certainly it was useful in 7.x to start off a poll with some number or to manually alter the number of votes a poll has at an arbitrary time. At present this appears to be a hold over from the 7.x version that does need thinking about in terms of an 8.x world. Having it as a weighting field as it currently appears to be calculating is a bug and should be addressed.

I wonder if we need to implement some method of generating votes here. This would allow us to arbitrarily add or remove votes from particular choices. The other thing we could implement is a modifier (+/- some number). That way, we maintain the number of votes a poll has from users voting and modify either up or down based on the value assigned in the field (an addition/subtraction modifier rather than a multiplicative one).

From PollStorage.php

    // Replace the count for options that have recorded votes in the database.
    // Multiply by the vote value for each option.
    $optionValues = $poll->getOptionValues();
    foreach ($results as $result) {
      $votes[$result->chid] = $result->votes * $optionValues[$result->chid];
    }

I would venture that this method could instead +/- a modifier. We would then also have to be concerned with the poll edit form and ensure that any modifier to vote count took into account existing number of votes.

The default value for a new choice would also be 0 as opposed to the 1 that it currently is.

Probably there's a bug in the way the calculation is being done at the moment. IIRC, I was thinking of a weighting system or some instances in which some votes are wrong. I think I got that idea from advanced poll, if I'm not mistaken.

It seems to me going for the simple poll concept where each option counts as 1 vote is the way to go right now. Maybe we should hold off on a more complex logic until later?

Agree that this should be changed to just adding/subtracting integer values from a vote option. Further work for vote generation can be added at a later stage.

I've now gone back to look at what we currently have and this is what I've got.

This effort wasn't a direct port of the old Poll module and from https://www.drupal.org/node/1266336 it was inferred that the D8 work on poll shouldn't be. Currently, the votes are not stored simply as +1 against options when users cast their votes. Instead, when they vote, the following are stored: who voted (uid), the poll they voted on (pid), their choice (chid), when they cast their vote (date/time) and where they voted from (ip address).

To know how many users voted in a poll for each option, an aggregation query is run, grouping vote results by the choice id.

In one of the discussions, which I couldn't find, there was also the idea of choice weights (i.e. a vote may have a value of more than 1). I liked the idea of being about to give choices same or different values. That's why after getting the number of users that selected an option, the count was multiplied by the value of the choice made.

The only issue I can see now is that a choice can have a value of 0. That's because the default widget of the poll choice field, sets the #min property of the "vote" element to 0. If that property is removed then we'll have to think of how to implement negative poll choice values.