We were already saving it as a time, but we didn't offer an interface to select the time due to lack of decent browser support for this field back when this feature was added. However, nowadays all major browsers support this field type and, at the time of writing, at least 86.5% of the browsers support it [1]. This percentage could be much higher, since support in 11.25% of the browsers is unknown. Note we still need to support the case where this field isn't supported, and so we offer a fallback and on the server side we don't assume we're always getting a time. We're doing a strange hack so we set the field type to text before changing its value; otherwise old Firefox browsers crashed. Also note that, until now, we were storing end dates in the database as a date with 00:00 as its time, but we were considering the poll to be open until 23:59 that day. So, in order to keep backwards compatibility, we're adding a task to update the dates of existing polls so we get the same behavior we had until now. This also means budget polls are now created so they end at the beginning of the day when the balloting phase ends. This is consistent with the dates we display in the budget phases table. Finally, there's one test where we're using `beginning_of_minute` when creating a poll. That's because Chrome provides an interface to enter a time in a `%H:%M` format when the "seconds" value of the provided time is zero. However, when the "seconds" value isn't zero, Chrome provides an interface to enter a time in a `%H:%M:%S` format. Since Capybara doesn't enter the seconds when using `fill_in` with a time, the test failed when Capybara tried to enter a time in the `%H:%M` format when Chrome expected a time in the `%H:%M:%S` format. To solve this last point, an alternative would be to manually provide the format when using `fill_in` so it includes the seconds. [1] https://caniuse.com/mdn-html_elements_input_type_datetime-local
CONSUL
Citizen Participation and Open Government Application
This is the opensource code repository of the eParticipation website CONSUL, 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 fork, install it, customize it and learn to use it from an administrator/maintainer perspective.
CONSUL 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.6, 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
