Feature #2104

module and/or plugin for voting

Added by Thomas Capricelli over 13 years ago. Updated about 13 years ago.

Status:ClosedStart date:2008-10-28
Priority:NormalDue date:
Assignee:-% Done:


Category:Plugin API
Target version:-
Resolution:Wont fix


The team in charge of a project may need to vote for something (much like a poll, actually). Typical case : a design decision.

Adding such a feature seems to me quite orthogonal to current features, so this probably doesn't change redmine design, nor would it bloat redmine source code

The idea is not to propose a poll like seen on most website, which are used , but rather a tool do make decision. That's why i've called that 'voting' and not 'polling'. For example, there could be several votes at some given moment, and those votes would have a dedicated tab, not appearing on the main project page.

Note that this is different from #1011, which is 'voting for bugs', or #1158 (more like 'random poll on websites', not clear what people want, standalone or linked to an issue). I hope I describe it here clearly enough so that there's no ambiguity on the intended use.

Here's a description of how i see this (subject to comment, of course)


There's a module called 'Voting' that you can select on a per-project basis. I guess that it being a plugin is an implementation issue.

Structure of a vote (db description)

  • A title (string)
  • A description (for example with a link to a wiki page, or to specifiy until when the vote is opened)
  • A state (boolean) : opened or closed
  • A boolean flag : internal (see below)
  • A list of strings, from which voters will select one and only one.

global changes

  • There's a new permission "Can handle vote"

How it works

  • Once enabled, roles having the permission "Can handle vote" can add a vote, which by default is 'opened'.
  • if the flag internal is set to true, only the members of the project see the vote, and can vote. If set to false, everybody can see/vote. Note that this is different from the 'public' flag of the project. Of course, if the project is private, then there's no point in having a vote with internal=false.
  • In any case, only identified people can vote, to facilitate the design.
  • When the vote is 'opened', people (everybody or only members, according to the internal flag) can vote and change its vote.
  • Roles having the permission "Can handle vote" can close the vote
  • When the vote is closed, nobody can vote or change its vote anymore, but the result is still displayed (to everybody or only project members, according to the internal flag).

Examples of votes

  1. An internal vote for choosing the best library to use for some given requirements.
  2. An external vote to ask users which feature they prefer for the next release.


Maybe instead of using the internal flag, it would be wise to use redmine roles for that, but i'm not sure how to do that.

I don't think it is necessary to specify the date of closing to redmine so that no human intervention is needed.

Future / more features

Could be:
  • an option to display, or not, the current number of votes and the current result, while the vote is opened
  • other fields than just list of strings. For example several lists which one choice in every list, or people entering a number between given min/max values.

issue_vote.png (15.5 KB) Andrew Chaika, 2009-04-18 18:46

issue_vote_query.png (61.7 KB) Andrew Chaika, 2009-04-18 18:46

Related issues

Related to Redmine - Feature #1158: Polls New 2008-05-01


#1 Updated by Marcus Riemer over 13 years ago

This comes very close to a feature I would love to see: Some kind of "Decision" tracker. None of the existing trackers really applies to this situation :(

#2 Updated by Thomas Capricelli over 13 years ago

yes, 'decision taking' is my main usecase for this feature.

Thought i think it would be great too to have polls to get feedback from unpriviliged people as well.

#3 Updated by Maxim KruĊĦina over 13 years ago

It's good idea, but still I think it can be great to integrate also per-ticket voting and put it into sigle "Voting" plugin.
When voting for tickets, there should be selectable for which trackers can user vote (for exaplme we'll vote in Feature and Idea trackers, not in Bug and Support)

#4 Updated by Jens Goldhammer over 13 years ago


#5 Updated by Mischa The Evil about 13 years ago

  • Status changed from New to 7
  • Assignee set to Mischa The Evil

I'll start some work for a plugin-implementation of issue-voting soon...
More to come...

#6 Updated by Thomas Capricelli about 13 years ago

@Mischa The Evil

well.. this is not really issue voting (as in #1011), rather a decision-taking process, involving non-members, or not.

#7 Updated by Mischa The Evil about 13 years ago

  • Assignee deleted (Mischa The Evil)

Thomas Capricelli wrote:

@Mischa The Evil

well.. this is not really issue voting (as in #1011), rather a decision-taking process, involving non-members, or not.

Ok, this wasn't clear to me in first instance. Thanks for notifying... ;)

#8 Updated by Andrew Chaika about 13 years ago

I have developed alfa version of issues voting plugin:

#10 Updated by Eric Davis about 13 years ago

  • Status changed from 7 to Closed
  • % Done changed from 0 to 100
  • Resolution set to Wont fix

I'd be happy to let Andrew Chaika maintain this feature as a plugin. Having this feature in a plugin is best because it will keep the core for maintainable but allow others to work on it at their own pace.

Andrew Chaika: could you provide a link to your code repository so we can contribute to the development?

Also available in: Atom PDF