To get the heading where a user voted, we were relying on the `balloted_heading_id` field. Our guess is this was done so the total number of users is the same as the sum of users who voted on a heading. That is, if 2000 people voted just on the "All city" heading, 1000 voted just on the "North district" heading, and 500 people voted on both, instead of showing "3500 people voted in total, 2500 voted in all city, 1500 voted in north district", we show something like "3500 people voted in total, 2250 voted in all city, and 1250 voted in north district". However, this approach has some disadvantages. The first disadvantage is, the stats aren't correct. In the case above, 2500 voted on the "All city heading", so the statistics for this heading don't show reality. The second one is we weren't considering the last heading where users voted inside the budget being displayed, but the last heading where users voted, period. That means that, if all the people above voted on a later budget, the stats for the budget above would become "3500 people voted in total, 0 voted in all city, and 0 voted in north district". That also means we were including headings from previous budgets in the statistics for more recent budgets when people hadn't voted on the recent ones. So we're removing the `balloted_heading_id` since its data is lost once people vote on a new budget. And, in order to show the right stats and simplify the code, we're no longer trying to add votes just to one heading when users vote on several headings. Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
CONSUL DEMOCRACY
Citizen Participation and Open Government Application
This is the opensource code repository of the eParticipation website CONSUL DEMOCRACY, originally developed for the Madrid City government eParticipation website
Documentation
Check the ongoing documentation at https://docs.consulproject.org to learn more about how to start your own CONSUL DEMOCRACY fork, install it, customize it and learn to use it from an administrator/maintainer perspective.
CONSUL DEMOCRACY Project main website
You can access the main website of the project at http://consulproject.org where you can find documentation about the use of the platform, videos, and links to the community space.
Configuration for development and test environments
NOTE: For more detailed instructions check the docs
Prerequisites: install git, Ruby 2.7.7, CMake, pkg-config, shared-mime-info, Node.js and PostgreSQL (>=9.5).
git clone https://github.com/consul/consul.git
cd consul
bundle install
cp config/database.yml.example config/database.yml
cp config/secrets.yml.example config/secrets.yml
bin/rake db:create
bin/rake db:migrate
bin/rake db:dev_seed
RAILS_ENV=test rake db:setup
Run the app locally:
bin/rails s
Run the tests with:
bin/rspec
You can use the default admin user from the seeds file:
user: admin@consul.dev pass: 12345678
But for some actions like voting, you will need a verified user, the seeds file also includes one:
user: verified@consul.dev pass: 12345678
Configuration for production environments
See installer
Current state
Development started on 2015 July 15th. Code was deployed to production on 2015 september 7th to decide.madrid.es. Since then new features are added often. You can take a look at the current features at the project's website and future features at the Roadmap and open issues list.
License
Code published under AFFERO GPL v3 (see LICENSE-AGPLv3.txt)
Contributions
See CONTRIBUTING.md
