GNU Health/Contributing

From Wikibooks, open books for an open world
Jump to: navigation, search

GNU Health is a FLOSS project, you are very welcome to contribute to it. There are several ways to do so, most of which not requiring you to know how to code!

Translating[edit]

Providing GNU Health in a user's native language is a big part of the success. You can help by improving existing translations, or creating a new translation in your own language! Translating GNU Health is easy, it does not require technical knowledge, and is all done via a web interface. Have a look at the Localization page for more details on the process.

Reporting bugs[edit]

Unfortunately most (if not all?) software contain bugs. While we're actively working on fixing them so you don't have to struggle, please do report any bug or anomaly that you encounter.

Reporting a bug does not take much time. It is done via Savannah.

Tip: for faster resolution, please include a description of the steps you performed to get to the bug, and if possible include screenshots of the issue. But be careful: don't include patient information in the screenshots or your description!

Coding[edit]

GNU Health is mostly a set of Tryton modules, the programming language used is Python. The code is hosted on Savannah and versioned under Mercurial.

Obtaining your copy of the code[edit]

You can get your copy of the latest code by doing an anonymous checkout:

hg clone http://hg.savannah.gnu.org/hgweb/health/

You can also browse the code online.

Customizing and creating your own modules[edit]

Chances are that if you are installing GNU Health for your center, you will be customizing it to feed your specific needs. Reports, access controls, views are just some of the objects that are normally customized. The main concept is to not touch the standard code or modules , since it will be overwritten in the next update and most probably will end up in a broken system.
The recommended steps to customize GNU Health to your center are :

  1. Create your module : It's highly recommended that you use the following naming convention for your local modules : z_health_<modulename> : For example, if your project is called catalina, your local module name would be z_health_catalina . This way makes is easy to detect and differentiate your modules from the base code. You can also easily make backup of them following the pattern.
  2. Inherit the objects
  3. Modify or create new models.


If you create a new custom field, you should also use the z_<fieldname> naming convention. This avoids collision with future field names of the official releases. We will not use any module, class, or model name starting with "z_".

Since GNU Health 2.6 there will be a directory called custom under ~/gnuhealth/tryton/server/modules . Please put your local modules that contain the customizations for your project under this directory.

Please refer to the Tryton developer Guide for more information about creating a module.

Submitting patches[edit]

Regular contributors have write access to the code repository. However, if you're just starting out, we want to make sure that your changes get reviewed. The way to do this is to open a bug describing the issue you've fixed or the feature you've added, and to attach a patch to that bug report. One of the developers will review your patch and commit it to the main development branch if approved.

Upgrade · Localization