Thanks 
I’ve prevented anonymous users from seeing the election controls and protected the server methods.
Also I’ve added the setting min_trust_to_self_nominate (default: 1).
https://github.com/angusmcleod/discourse-elections/commit/7320f8290d4758a631a3ecd3fdba7e91b6eaf8e2
And don’t forget to catch promise failures in the JS - network failures, etc. shouldn’t result in infinite spinners 
Any time you write this.set(‘loading’, true) you need to add a .finally(() => self.set('loading', false)) clause.
We also had requests for limiting to discourse groups for self nomination and voting. Not a high priority for us but you may be interested in considering.
@riking Thanks, that’s useful. Using your advice, In addition to the self-nomination toggle method, I’ve added a finally statement to each of the ajax calls in the manage-election controller (which do things like update the election title, change the status etc). This means my generic resolve function is always called at least once (normally twice), and that regardless of the outcome the result of the election update will always be cleared after a short timeout.
resolve(result, type) {
if (result.success) {
this.set(`${type}Icon`, 'check');
} else if (result.failed) {
this.set(`${type}Icon`, 'times');
this.flash(result.message, 'error');
} else {
setTimeout(() => {
this.set(`${type}Icon`, null);
}, 5000);
}
this.set(`${type}Saving`, false);
}
This behavior is cleaner.
@tobiaseigen Group limitation for self-nomination concerns this plugin (on the to do list), but the limitation of voting concerns the polling plugin (can discuss further in a polls topic).
I suppose that means there is no possibility for secret ballots, i.e. so that not even an admin can tell who voted for whom?
People are already using database queries to get the list of voters in a poll, so no. Any potential solution to that is useless against database access.
Actually, there is a potential solution but it requires never being able to change your vote and I’m not sure there’s interest in adding that to polls?
(Namely: store list of usernames, and map of option to vote count. Because you don’t know who voted for what, no take-backs.)
And even worse: It still requires trusting the admins, because (barring very, very complicated cryptography) there is no way for users to tell whether the server secretly stores their votes or not!
I think that would be an option worth implementing, despite the shortcoming. Reason: it is a common requirement in the statutes of associations that elections are conducted via secret ballot. If the plugin doesn’t even come close to this, there is no chance such organizations could use it…
Keep in mind that all elections require ‘trusting the admins’ to a certain extent. Just because it’s possible for an admin to figure out what your vote was, it doesn’t follow that the ballot is not secret. There is a difference between ‘no one could ever find out no matter how hard they tried’ and ‘if everyone acts properly, no one will know’.
There’s an argument that this behavior should be the default on all polls. People’s voting choices are affected by a whole host of factors that change over time, in particular other people’s votes. Allowing you to change your vote allows for the effect of these factors to exacerbate, particularly after you’ve seen the results.
I’m not sure what benefit is derived from allowing people to change their vote on any poll.
So you no longer think it is doable? Or are you suggesting the change should be implemented in the poll feature on which you build?
When I initially wrote that I was slightly hung-over and hadn’t thought it through
On reflection, I do think it would be a bit complex to implement a 100% secret ‘no admin can figure out your vote through db queries’ changeable-vote poll.
But, as suggested, I think this is the wrong focus for two reasons.
I’m not sure that the fact that there is a record of voter’s actual votes somewhere invalidates the secrecy of the ballot. There are many instances in real-world elections when it is possible for an election administrator to undermine the election. Ballot boxes can be stuffed, votes can be changed after the fact, cameras can be installed in voting booths, voters can be intimidated… Such things can and do happen in real world elections. What makes a valid election is not the impossibility of these things occurring, but them not occurring in fact. Making a completely incorruptible system would be ideal, but it’s not necessary to make the process valid. A simple solution is for the administrators to simply refrain from querying the db. Like election administrators in real life elections refrain from changing votes.
I do think that the default for any Poll (election or otherwise) should be one vote per user per poll. This goes to the reason why almost all polls (election or otherwise) in real life are conducted within a short window of time: as far as possible, all votes are cast within the same factual context. If the changes in factual context are not taken into account a poll (any poll) is pretty meaningless, as it’s not constituted with similarly situated choices.
I would note in passing that automatic time limiting for polls is one possible feature that could help in this respect, however it’s not really material to the current discussion as whoever posts the poll can just say when the poll will close and close it then.
One material aspect of this is knowledge of other people’s votes. It would be better, from a poll-mechanics perspective, to not allow people to see the results of a poll prior to voting. Showing results to a voter after they have voted and then allowing them to change their vote is also not desirable from a poll-mechanics perspective. This issue has been discussed on meta before.
The trickier situation is when you have a poll with results that are hidden until voting is closed. In this situation you might initially think that not allowing people to change their votes violates the principle of ‘same factual context’ more than allowing it does, as polls (particularly internet polls) are necessarily conducted over some period of time, so if there is a material change in the factual context over that period it is better to give the people who voted early an opportunity to change their minds. In fact, there are a handful of U.S. states that allow early voters to change their vote prior to an election day.
However I would argue that, when considering what the desired default should be, we need to take into account a few other factors:
Changing ones vote in a poll (any poll) is not a standard action. Most voters in a poll will only vote once, regardless of whether they can change their vote. Those who do change their votes (for whatever reason) will skew toward those who are more heavily invested in the subject matter or the outcome.
Allowing votes to be re-cast multiple times lessens the import of casting a vote. Part of the function of allowing a voter to only cast their vote once is to force them to thoroughly consider their reasons for deciding. In the same vein, I think it is better to structurally preference a priori reasoning over a posteriori reasoning. The latter is more likely to be influenced by more immediate factors.
In most situations in which there have been material changes in the factual context during the voting window, it would make more sense to create a new poll rather than try and ‘assimilate’ the new facts into the context of the old one. Polling firms don’t conduct one massive poll over the course of an election campaign and try to assimilate the old preferences into the context of the new ones. They conduct multiple polls at particular times.
Will I work on submitting PRs for hidden results and single vote polls to the polls plugin? Maybe I’ll see what my schedule is like next week…
I basically agree with what you say and it would be great if you’d find the time to implement your suggestions 
If you could link the closing of a poll to the closing of the topic, we’d already have automatic time limitation (via the topic timer). The only potential limitation would be that you need to be staff (or even admin?) to do that so that this would not be available for election owners who are not staff. But if the election is so important that the reliable closure is important, you’d assume staff is involved anyway…
I agree that 100 percent guaranteed secrecy should not be the goal here but rather a legally acceptable guarantee. My non digital example would be that in a smaller AGM, for example, it is conceivable that election officers recognise someone’s handwriting or the way someone folded the paper. But we routinely choose to ignore this and in the same way we should find a digital solution where members will similarly choose to ignore possible (but unlikely) leaks. Or, since you are a lawyer: where they can be legally expected to do so.
So, the devil is in the details: I think if people’s votes could be revealed through a simple db query, this would not be sufficient IMO. But I understand that the idea with a separate table for who voted instead of saving what they voted fixes exactly that, right?
Yes it will fix it, but it entails also restricting users to one cast of their vote per poll. From a code logic perspective, if you just know who has voted, but not for whom, if a user changes their vote there’s no way of knowing which vote tally to deduct a vote from.
So we’re actually talking about three changes here.
One cast of your vote per poll (which should really be the default);
If ‘one cast’ is on, you also have the ability to completely anonymize the votes, even on the db, by using a separate ‘voted’ list.
The ability to hide the results prior to the closing of the poll and / or prior to a user casting their vote.
That should really also be the default (though I understand the use case of more informal straw-poll type polls)
Minor UX issue - on the poll it’s too easy to accidentally click through to the user profile rather than placing a vote for the user
I just noticed that when the electinos plugin is enabled, the poll option label text disappear when there is an emoji on the label. The emoji shows, but not the text. This is in regular single option polls, not actual elections. I tried a bunch of things, including putting the same poll on try where it then worked.
I’ve now disabled the elections plugin and the poll option label texts and emojis are back.
Thanks fixed.
https://github.com/angusmcleod/discourse-elections/commit/2319e1ddf14c37e694c995b29a9b0377d090c5d5
While I’m here, I should note that I’ve been adding various features to this plugin over the last couple of weeks:
Automatic poll open and close. You can set an election poll to automatically start X hours after X nominations are received; or at a certain time. Likewise with poll closing, you can set a certain time period (in hours) or a certain time. When a poll is scheduled to open or close (whether by reaching a nomination threshold or via a manually set time), the time is displayed under the topic title.
You can set this up when you create an election or after an election has started in ‘Manage Election’.
Election status banner. You can add a banner to category topic lists and inside topics themselves, telling your community that an election happening.
Gosh I love all your work so much, this plugin is awesome and makes the self governance of the project i’ve been admining for so much easier. However, they have issues where sometimes seats go with one nominee. This doesn’t work in the current implementation and it’d be great to see some sorta way to handle this scenario.
Like presumed election, or maybe even an election adminstrator setting to allow it have a “no vote” option for certain types of elections.
Thanks for everything you do @angus
An election with one nominee?
hm. I guess I could add that as a feature. I’m a little curious as to why you would bother to run the election at all in that case though
You could just anoint the one nominee as the new officeholder at the end of the nominating period.
