Condorcet full ranking
At the beginning, there were two Condorcet options, one traditional (truncation permitted), one full ranking (each candidate must be strictly ranked). The latter is no longer supported. This option has been removed. The code is actually still here. The only thing that's changed is that the relevant option has been removed from the posting template, preventing people from creating a poll using that option
It can quite easily be put back if there is strong demand for it.
Beware though that newer code since version 0.16 did not take full ranking Condorced into account. For example, the option to be able to change one's vote at a later date (version 0.18) has not been implemented for this voting method.
Changing ballots
Privacy issues
Since version 0.18 of the MOD, users are given the choice to choose to be able to update their vote at a later date. If they don't select this option, we just record the fact that they have voted in that poll, but nowhere there is any record of what they actually voted.
If on the other hand, they choose to keep the option to change their vote later, we need to know what they voted. In that case, the information is stored in the vote_ballots table. Currently, the selected (voted for) options are stored as a string together with the user_id.
What this means is that the information about who voted what is fairly easily available to anyone having direct access to the database. Typically, this would be the webmaster. The webmaster of www.masquilier.org (myself) really doesn't care about anyone's political preferences. My goals are well known, and spying on people's votes would certainly not advance my cause. This MOD however maybe installed in many different websites who use phpBB. In such cases, it is unknown what (very unlikely) situation might arise, where a webmaster would abuse their power and use it against the wishes of the user. Yet, in probably over 99% of the cases, the voter wouldn't consider their opinions so private that they'd want to be over 100% sure that nobody has access to their votes. After all, we are not speaking about credit cards here. People tell freely about their political preferences in mailing lists and forums all around the world.
Let's also consider the fact that the code is php and opensource. It's easy to modify by any one, so there would never be a garanty that the code used by a webmaster in another site will be the one coded by us. At the end, it all boils down to a problem of trust in a site's host. Worried users will not post anything in the first place anyway.
Considering all of the above, storing the user_id alongside to the ballot they cast (having given the user the choice to do so or not) is not an ideal situation as far as privacy is concerned, but I consider it to be a minor issue. If the user disagrees, they are free not to check the related option when casting a vote.
Solution to be implemented
Of course, we can think of many solutions. One I am currently thinking about is to store the user_name in a hash form, or encrypt the user name with a user provided password. This would make things much more complicated (for the user as well as for the coder!) but hey! if people are so worried about privacy issues, why not?
It takes time to develop this and test it. Currently I prefer to allocate my limited time on other development aspects of this web site. Whether I do it soon or not also depends on user request. As for everything else, you can discuss this topic in the relevant forum in the Agora.
Data base handling
In posting_election_method.php, there are a lot of SQL queries, many of which should be committed together, for consistency. They are part of a single transaction. Review the code to make it more consistent with DB handling good practice.
