Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow a higher number of votes than options at creation time #372

Open
Manuzor opened this issue Feb 22, 2021 · 2 comments
Open

Allow a higher number of votes than options at creation time #372

Manuzor opened this issue Feb 22, 2021 · 2 comments
Labels
1. To Develop Tech/Server Plugin Server Type/Enhancement New feature or request

Comments

@Manuzor
Copy link

Manuzor commented Feb 22, 2021

Currently, there's no way (that I'm aware of) that would allow users to add options and to have everyone able to vote for all options. The number of votes per user is currently set at creation time of the poll and is capped at the number of options at that time. However, when a new option is added later by someone else, the maximum number of votes per user stays the same.

With the experimental GUI this means that right now the maximum number of votes allowed is 3 since there's no way to add more than 3 options at creation time.

I suggest removing the upper limit on votes altogether. This would allow the creator of the poll to just specify --votes=99 and be done with it.

I suppose this the function that would have to change:

// validate checks if poll is valid
func (p *Poll) validate() *ErrorMessage {
if p.Settings.MaxVotes <= 0 || p.Settings.MaxVotes > len(p.AnswerOptions) {
return &ErrorMessage{
Message: &i18n.Message{
ID: "poll.newPoll.votesettings.invalidSetting",
Other: `The number of votes must be a positive number and less than or equal to the number of options. You specified "{{.MaxVotes}}", but the number of options is "{{.Options}}".`,
},
Data: map[string]interface{}{
"MaxVotes": p.Settings.MaxVotes,
"Options": len(p.AnswerOptions),
},
}
}
return nil
}

@kaakaa kaakaa added 1. To Develop Tech/Server Plugin Server Type/Enhancement New feature or request labels Feb 23, 2021
@OnlineCop
Copy link

There might be a few ways to handle this. Assuming the following for illustration:

  • the poll was created with 4 default options: /poll "Should users add options?" "Yes" "I guess" "Better not" "No" --public-add-option
  • two options were submitted by users: "On the fence", "HR would disapprove"
  1. --votes=n could allow n <= 0:

    • n>0 indicates the hard limit of all options, whether default or user-submitted.
    • n=0 indicates "max" votes: users may vote for any/all default or user-submitted options.
    • n<0 indicates the hard limit of votes for default options (its absolute value would be used, examples below), but users receive one additional vote for each user-submitted option.
      • Given --votes=0, users have 6 votes: 4 for the default ["Yes" "I guess" "Better not" "No"] options, plus 2 for the user-submitted ["On the fence", "HR would disapprove"] options.
      • Given --votes=-1, users may only select 1 from the default options, but may additionally select one or both from the user-submitted options.
      • Given --votes=-2, users may select 2 from the first default options, and one or both from the user-submitted options.
    • This has the disadvantage that the poll creator couldn't limit votes for user-submitted options: if there were 10 user-submitted options, a user would have abs(p.Settings.MaxVotes) votes for default options plus 10 more votes for each of the user-submitted ones.
  2. --votes=n could allow n = 0, and add --public-add-option-vote=m where m >= 0:

    • Users would only be allowed to use these votes toward user-submitted options, not toward default options.
    • n=0 indicates "max" votes for default options, but does not affect votes toward user-submitted options.
    • m=0 indicates "max" votes for user-submitted options; for each user-submitted option, 1 extra vote is given to each user.
    • m>0 indicates the hard limit of votes for user-submitted options.
      • Given --votes=1 --public-add-option-vote=0, users have 3 votes: 1 for the default ["Yes" "I guess" "Better not" "No"] options, plus 2 for the user-submitted ["On the fence", "HR would disapprove"] options.
      • Given --votes=1 --public-add-option-vote=1, users have 2 votes: 1 for the default options, plus 1 for the user-submitted options.
      • Given --votes=1 --public-add-option-vote=10, users have 3 votes: 1 for the default options, plus 2 for the two (existing) user-submitted options. As more user-submitted options were added, users would gain additional votes, up to a max of 10 votes (for user-submitted options). Therefore, if 15 user-submitted options were provided, '10' would still be the upper limit.
      • Given --votes=0 --public-add-option-vote=1, users have 5 votes: 4 for the default options, plus 1 for the user-submitted options.

These ideas aren't exhaustive; feel free to reply with suggestions/additions.

@naresh97
Copy link

I'm working around this issue by simply removing the upper limit, although I consider that a hacky fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. To Develop Tech/Server Plugin Server Type/Enhancement New feature or request
Development

No branches or pull requests

4 participants