Customizing OpenPetra: Difference between revisions
Jump to navigation
Jump to search
Joejoe2010 (talk | contribs) No edit summary |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
see also [[Building and maintaining customized versions of OpenPetra]] | |||
== How other projects are making customization possible == | == How other projects are making customization possible == | ||
* OpenERP: | * OpenERP: | ||
| Line 24: | Line 26: | ||
* customize by using the database | * customize by using the database | ||
** tables with settings (user settings, organisation wide settings) | ** tables with settings (user settings, role settings, organisation wide settings) | ||
** Advantages: no additional files; can be used without restart | ** 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) | ** 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) | ||
| Line 36: | Line 38: | ||
** Disadvantages: perhaps the time for locating plugins could be too long? solution: cache dll mdsums, store extracted methods in config files etc | ** Disadvantages: perhaps the time for locating plugins could be too long? solution: cache dll mdsums, store extracted methods in config files etc | ||
== Using | == Using bazaar to manage customizations == | ||
The idea of a friendly fork is | 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 need your own customizations for your organisation, and you need to keep them in a repository | ||
Latest revision as of 11:40, 18 Haziran 2011
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
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.