9da44a4538
In the past, we've run into situations where we commited a version of the schema.rb to version control which wasn't in sync with what you get when you create the database and run the migrations. This is something that might happen if you're working on different branches at the same time, run the migrations in all those branches, and then commit the current status of your database to your current branch. That will result in a schema file which contains the database changes done in all these branches instead of just the current one. Although this hasn't happened to us for years, we see it happening sometimes in other COSUL installations, and there's always a chance that we make a mistake and do it again. Until now, it wasn't a big deal because the installer sets up the database by running `db:create db:migrate`, which runs the migrations instead of using the `schema.rb` file. However, we're going to add multitenancy using the Aparment gem, and this gem uses the `schema.rb` file when creating a new schema for a new tenant [1]. If the `schema.rb` file contains changes that shouldn't be there, this will lead to different database schemas having different tables and/or columns and future migrations might crash on production when applied to some of these schemas. In other words, this mistake could now result in a disastrous situation. To help preventing that, we're adding a CI workflow that checks the current `schema.rb` file is in sync with the database migrations. [1] https://medium.com/infinite-monkeys/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f#7e97
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