Development work on CoVE by Open Data Services is carried out in sprints. The issues for each sprint can be found at https://github.com/OpenDataServices/cove/projects . Other work is carried out from time to time, and contributions from the community are welcome. Outstanding issues for CoVE can be found at https://github.com/OpenDataServices/cove/issues . Please report any bugs!

CoVE is an web application to Convert, Validate and Explore data following certain open data standards - currently 360Giving and the Open Contracting Data standard. http://cove.opendataservices.coop

The W3C Data on the Web Best Practices recommend making open data available in a range of formats to meet the needs of different users. Developers may want JSON, researchers might prefer a spreadsheet format.

CoVE manages the process of converting between JSON, Excel and CSV formats for structured data.

CoVE presents key validation information during the process, and can be configured to display information about the contents of a data file, so that it can be easily inspected.

CoVE currently supports conversion from:

• JSON to multi-tabbed Excel files
• Excel to JSON (it uses the flatten-tool for conversion)

If a JSON schema is supplied, CoVE can use either field names or user-friendly column titles.

Overviews of how users flow through the application are maintained at https://docs.google.com/drawings/d/1pVbEu6dJaVk8t3NctjYuE5irsqltc9Th0gVQ_zeJyFA/edit and https://docs.google.com/drawings/d/1wFH4lZlBZWso7Tj_g7CyTF3YaFfnly59sVufpztmEg8/edit

CoVE is in constant development. There are public instances in use at: https://dataquality.threesixtygiving.org/ http://standard.open-contracting.org/validator/

We deploy the latest version of CoVE at the end of each calendar month (usually the last Thursday of the month). We make a development version ready for user testing (mainly internally) two weeks before deployment. Our cut off date for new features to be considered in that cycle is the week before that.

Feature requests, bugs, questions and answers etc are all handled via GitHub. We use release cycle milestones to organise those issues. We also use GitHub projects as a way to prioritise issues and indicate what is being worked on.

Serious Bug fixes and 'priority' features, that need to make it into a release at short notice can be included by negotiation.

This application is built using Django and Python 3.5

Steps to installation:

• Clone the repository
• Change into the cloned repository
• Create a virtual environment (note this application uses python3)
• Activate the virtual environment
• Install dependencies
• Set up the database (sqlite3)
• Compile the translations
• Run the development server

git clone https://github.com/OpenDataServices/cove.git
cd cove
virtualenv .ve --python=/usr/bin/python3
source .ve/bin/activate
pip install -r requirements_dev.txt
python manage.py migrate
python manage.py compilemessages

Then, for 360Giving run:

DJANGO_SETTINGS_MODULE=cove_360.settings python manage.py runserver

Or for OCDS run:

DJANGO_SETTINGS_MODULE=cove_ocds.settings python manage.py runserver

Follow the instructions in your terminal to open the application in your browser.

The following steps are for Ubuntu but equivalent packages are available for other distros.

sudo apt-get install build-essential libxml2-dev libxslt1-dev python3-dev
pip install -r requirements_iati.txt

Then run the development server:

DJANGO_SETTINGS_MODULE=cove_iati.settings python manage.py runserver

See https://cove.readthedocs.io/en/latest/deployment/

./run_tests.sh

To run functional tests with a different browser:

BROWSER=Chrome ./run_tests.sh

See http://selenium-python.readthedocs.io/api.html for browser options.

To generate a coverage report (in the htmlcov directory):

py.test --cov cove --cov-report html

The tests include functional tests (actually interacting with the website in selenium). These can also be run against a deployed copy of the website:

CUSTOM_SERVER_URL=http://dev.cove.opendataservices.coop py.test fts

We also use flake8 to test code quality, see https://github.com/OpenDataServices/developer-docs/blob/master/tests.md#flake8

The development requirements include xdist to allow running tests in parallel:

py.test -n2

Translators can provide translations for this application by becomming a collaborator on Transifex https://www.transifex.com/OpenDataServices/cove

For more information about Django's translation framework, see https://docs.djangoproject.com/en/1.8/topics/i18n/translation/

If you add new text to the interface, ensure to wrap it in the relevant gettext blocks/functions.

In order to generate messages and post them on Transifex:

First check the Transifex lock, because only one branch can be translated on Transifex at a time.

Then:

python manage.py makemessages -l en
tx push -s

In order to fetch messages from transifex:

tx pull -a

In order to compile them:

python manage.py compilemessages

Keep the makemessages and pull messages steps in thier own commits seperate from the text changes.

To check that all new text is written so that it is able to be translated you could install and run django-template-i18n-lint

pip install django-template-i18n-lint
django-template-i18n-lint cove

Add a new requirements to requirements.in or requirements_dev.in depending on whether it is just a development requirement or not.

Then, run ./update_requirements --new-only this will populate requirements.txt and/or requirements_dev.txt with pinned versions of the new requirement and it's dependencies.

WARNING: The ./update_requirements script will delete and recreate your current .ve directory.

./update_requirements without any flags will update all pinned requirements to the latest version. Generally we don't want to do this at the same time as adding a new dependency, to make testing any problems easier.

CoVE for OCDS and IATI can be run from the command line. To get a JSON file with validation errors plus other key information, use the following command:

OCDS

./ocds-cli --options file-name

file-name can be a JSON or an Excel file.

Options:

--output-dir -o Directory where the output will be created, defaults to the name of the file.

--exclude-file -e Do not include the file in the output directory.

--delete -d Delete the output directory if it already exists.

--schema-version -s Version of the schema to validate the data.

--convert -c Convert data from nested (JSON) to flat format (Excel and CSV). This option is redundant for spreadsheets as they are always converted to JSON format.

IATI

./iati-cli --options file-name

file-name can be a XML or an Excel/CSV file.

Options:

--output-dir -o Directory where the output will be created, defaults to the name of the file.

--exclude-file -e Do not include the file in the output directory.

--delete -d Delete the output directory if it already exists.

--orgids -i Run org-ids rule check for IATI identifier prefixes.

--openag -a Run ruleset checks for IATI OpenAg data.

If the file is in spreadsheet format, the output directory will contain a unflattened.xml file converted from Excel or CSV to XML format

OpenaAg rulesets check that the data contains the XML elements <opeang:tag> and <location>, and that they include the right attributes expected for OpenAg data. Please read OpenAg ruleset feature files (written in Gerkhin style) for more information.

Org-ids rulesets check that all organisation identifiers are prefixed with a registered org-ids prefix. Please read Org-ids ruleset feature file for more information