Alternate solution to implement voting option in jira to allow to vote against an issue

[ashleyg]

Hi,

Currently jira built in voting button only allows to vote for an issue which means a yes. And those who do not vote for it are either the ones who never voted or voted against it. But those who want to vote against it can't do that through the voting button and we have an important requirement as such pertaining to this aspect in our organisation where we want to implement something similar so that we can track in real time who are the ones that negatively voted for an issue. As such comments are definitely not a good option.

I see there were couple of similar requests submitted to atlassian but were outrightly rejected and closed
https://jira.atlassian.com/browse/JRASERVER-756?error=login_required&error_description=Login+required&state=0592e4d8-363f-4623-8c2c-15fab6c8bc48
Also the closest plugin i see is :-
https://marketplace.atlassian.com/apps/1216689/voting-extension-for-jira?hosting=server&tab=overview

Is there an alternate way to do it without the usage of any additional plugins either through some fields or something in the workflow that we could implement? If not which would be the appropriate plugin to help achieve this functionality? Its such a normal functionality that you get to see in email outlook and still something we don't have in jira. Right now we are managing this "Yes" vs "No" vote options through outlook.

Cheers,

Ashley

[Nic Brough -Adaptavist-]

I'm afraid the (very very very basic) voting system in Jira is pretty much part of the core and the only way to get a better one is to use an app to do it.

You might be able to do something in workflow, or even outside it, but it would need coding itself.  With Scriptrunner, I've implemented a very very simple, but slightly improved system:

• Added five multi-user pickers (not put on screens), call them something like "vote level"
• Put web-fragments on-screen as a set of voting buttons each triggering a script, chosen by vote level (e.g. if they click on 4, use the script for 4, or pass 4 into a parameterised script)
• The script checks if the current user is currently in any of the user-pickers.
• If not, add them to the level they selected
• If they are in the level they selected, do nothing
• If they are in another level, remove them from that, and add them to the level they selected

That gave people more of a rating than a vote, but you can implement whatever scheme you wanted this way.

You'll want to create (some) scripted fields to display things like

• Your current vote on this is: (this one needs a bit of js to get current vote and decide what to show)
• X people have voted on this
• The average score is Y
• Amazon-like N people voted highest, M people scored it as mid-high, P people gave it a middling vote, etc

[ashleyg]

Thanks Nic for the suggestion. I believe we will eventually use script runner as its one single plugin that servers multiple purposes so worth every penny. Having said that if use it to implement what you are suggesting, what would be the simplest approach when it comes to let's say i have 5 fields for five different users and i would like each field to be editable by only that respective user and that field has the option for vote yes or no. So lets say five different custom fields namely A,B,C,D,E and each is a may be scripted custom field of type dropdown single select with options yes or no and only can be edited by its respective user. Or may be something similar if that helps what i am looking for.

[Nic Brough -Adaptavist-]

That was just an example of one scheme for voting that I did write once, there's plenty of other ways to do it.

The important thing, which I think you've stated more clearly than I did, is that you record who has voted for (or against) the issue so that they can only vote once.

Using my "custom field to store list of people" principal, for your Yes/No, you only need three, or possibly even two.  One for Yes, one for No, and (possibly) a third for "I want to tell you I have an opinion voted, but not for yes or no" if you want to record that.

Your approach of having a yes/no field that behaves differently per user may not be possible in Scriptrunner, I think you'll need a plugin with supporting code for it.  Scripted fields display data, they don't accept input.  You'd need a field that is a simple yes/no select list, but you'd need to capture every edit of it, work out what the intention is on edit, and then store something that captures a list of all the users who change it, and overrides the content.  You'd need a second field to store that calculated content, and the yes/no would not be able to display the value for the current user, you'd need another scripted field to show that (and I'm not sure you could do that because I don't think behaviours can work with view fields).  All of the data for all of those fields would be useless for display in other places as well.

[ashleyg]

Thanks Nic for the clarifications here and the insight.
After giving a though to it i am thinking what if we go with lets say five separate vote transitions (each with condition for each user) which will present a transition screen with that vote dropdown (yes/no) as required validator for each person. So lets say five people and five vote fields (one for each). Each transition will have a loopback transition as post function which means once the issue is created and is Open state, then there is a vote transition button for each of this people as they view the issue and the moment they click on that status transition, it updates the corresponding vote field (for that person), and as a post function performs another transition back to the original status. All of it seems easy to implement except for how to transition back to the original status as part of post function. Any suggestions? we don't want to use another plugin like JMWE. So anything that can be done within the native capabilities or via script runner should be fine.

[Nic Brough -Adaptavist-]

This will not work well - you would need a separate field for every single user to record their vote, and some way to stop a user changing other people's votes.

The process of updating a vote by workflow is sound though - you can loop a transition back to the same status, you don't need any scripting or code to do that.

[ashleyg]

Here is what i did and so far seems to be working great but is not a scalable solution.

• I added a new status in the existing workflow named Voted
• I went with the option for 5 distinct user votes so created five distinct transitions from Open state to Voted State and then a single backward transition from Voted to Open state. Each of the distinct transitions from Open to Voted lets say one of them being Vote by X, had a condition that says only user in this group can execute this transition. So individually added that user to its own distinct group, same for the other four users (so four distinct groups). Then created five distinct transition screens and each with a distinct custom field again named something like Vote by X. So for the first distinct transition along with condition, it has a field required validator for the field (Vote by X) on the distinct transition screen. At the end it has a post function that transitions the issue back to Open state (Had to use JMWE plugin as there was no pre defined option to do so in our jira 8.9.0 - very recent version).
• Created a separate view screen for the project screen scheme and added all these five custom vote fields to it. So these fields are not on create/edit screen at all.
• Tested the entire flow and all of it works great
• Only respective user can seen their vote transition tab and when they click it they are forced to choose yes/no for that distinct custom field on the transition screen and when they do that and submit, due to the post function the issue comes back to same original status of Open. The same user will continue to see the Vote transition tab as long as the issue is in the Open status which is justified and that can allow him to click that vote transition again in case he chooses to change his vote from yes to no or vice-versa. No other user can see that transition and can hence not edit or manipulate the vote custom field for each user
• Once all the users have clicked their vote transition tabs that would mean the issue is in Open state and the view screen will display the vote option for each user through those distinct custom fields.
• This is a very lengthy solution and not practically scalable, but there isn't anything else i could think of out of the box. Also even for this basic implementation had to rely on JMWE plugin to allow to transition issue through selected transition ID/Name.

[Jack Brickey]

My thoughts off the cuff....

• you could use the vote feature and simply consider it in the opposite form - a vote is to the Nay
• you could create a custom field (number) and have individuals increment it. Issues: folks could step on each other and must trust someone not to vote more that once and no way to easily see if you voted or not
• consider an addon like - voting-extension-for-jira 

[ashleyg]

Thanks Jack for the prompt response!
Anyway we could achieve this from a permission perspective. I know if you edit permission you can edit any field and so that won't work effectively for us.
Also from plugin perspective is voting-extension-for-jira the only plugin for this?