Customizing OpenPetra

see also Building and maintaining customized versions of OpenPetra

How other projects are making customization possible

• OpenERP:
  • http://open-net.ch/fre/Progiciel-OpenERP/Admin-guide-OpenERP/Customizing-OpenERP-objects
  • it seems the table is derived and the new field added
• Extending Adempiere: http://en.wikiversity.org/wiki/Extending_ADempiere
  • use general getter and setter from PO for custom columns
• Compiere
  • http://www.jorgjanke.com/2007/08/add-column.html

Things to customize

• support different languages (might need different layout as well)
• use special names that are wellknown inside your organisation (eg. FAMILY vs HOUSEHOLD)
• different layout for different Operating System environments (see problems with TableLayoutPanel on Mono)
• add plugins for banks and other specific tasks (there is an interface that needs to be implemented)
• add new database fields; this really needs to be thought through; it will probably be easier to add a generic field upstream to OpenPetra.org, and use it specifically in your organisation
• customized navigation structure; disable modules, etc; same for screens, hide some fields etc
• change behaviour; this could be quite tricky; does it need to be done on the server, on the client?
• different workflows etc

General possibilities

• customize by configuration files, that are loaded each time when OpenPetra starts
  • Advantages: easy to configure, to develop and test; quite transparent
  • Disadvantages: deployment to each client (though this should work with patch management anyways)

• customize by using the database
  • tables with settings (user settings, role settings, organisation wide settings)
  • Advantages: no additional files; can be used without restart
  • Disadvantages: need to write maintenance dialogs for settings; but this could be done in a quite generic way (eg. Firefox settings about:config, which looks like a registry)

• customize by generating code with different parameters and/or yaml files
  • Advantages: probably quite fast
  • Disadvantages: quite a lot of code; each customized OpenPetra needs to be compiled separately

• customize by using reflection: the client could pick up functionality from DLLs
  • Advantages: quite easy to install plugins etc
  • Disadvantages: perhaps the time for locating plugins could be too long? solution: cache dll mdsums, store extracted methods in config files etc

Using bazaar to manage customizations

The idea of a friendly fork is

• you need your own customizations for your organisation, and you need to keep them in a repository
• you want to continue to receive updates from the main development
• you still want to contribute to the main development

This should work quite well with git, since it is a decentralised repository.

See also this page that describes how to use a repository-based decentralized collaboration.

Therefore, you create your own master repository, which you have to back up. Then you make your clone the master repository to a working repository, and then you configure your working repository to merge automatically (as described in the weblink above) from the remote repository, which is the OpenPetra repository at Sourceforge. You can still create patches and send them to OpenPetra via email.