Developer FAQ

Return to developer
documentation index

Get/update a developer CVS version

Make a backup of your configuration file and data

If you have already a working installation, backup your file htdocs/conf/conf.php and your documents directory. It more secure if you make a mistake later.

Get last version of sources by download

This method allows you to get CVS version of main development branch (called HEAD). This operation consist to get last version of Dolibarr files that are packaged each night into a zip file. For this, go on page with last CVS version of the day.

New files will overwrite old ones.

Get last version of sources using CVS

Another way to get last CVS version is to go use CVS tools. You can use the CVS server in anonymous mode, if you have a CVS client (CVS command line tool with Linux, or TortoiseCVS for example with Windows).

The command to get a full snapshot (with no CVS hidden files) in working directory is:

CVSROOT=:pserver:anonymous@cvs.savannah.nongnu.org:/cvsroot/dolibarr
export CVSROOT
cvs -q checkout -r HEAD dolibarr

HEAD means we want last version of files (so last development files).

The command to update files that was caught with previous CVS command: With linux (script shell):

CVSROOT=:pserver:anonymous@cvs.savannah.nongnu.org:/cvsroot/dolibarr
export CVSROOT
cvs -q update -P -d

With Windows and Tortoise cvs

"C:\Program Files\CVSNT\cvs.exe" -q update -P -d
CVSROOT=:pserver:anonymous@cvs.savannah.nongnu.org:/cvsroot/dolibarr

And to set back all your working directory with same files than on CVS server repository (canceling your local changes): With linux (script shell):

CVSROOT=:pserver:anonymous@cvs.savannah.nongnu.org:/cvsroot/dolibarr
export CVSROOT
cvs -q update -P -C -d

With Windows and Tortoise cvs

"C:\Program Files\CVSNT\cvs.exe" -q update -P -C -d
CVSROOT=:pserver:anonymous@cvs.savannah.nongnu.org:/sources/dolibarr

May be, you will have to change permissions on directories or files after to make then readable by users of your Dolibarr web server.

Get files for a CVS branch

If you want to work on a particular version (with its patches), you must follow same process but you must replace HEAD by name of the branch. For example DOLIBARR_2_2_BRANCH for branch 2.2 or DOLIBARR_2_4_BRANCH for branch 2.4.

Restore your configuration

Restore configuration file (./htdocs/conf/conf.php) with backup made previously if file has been erased/removed.

Update database

Next step is ti upgrade your database. For this, all you have to do is call page http://myrootdolibarr/install/ and choose option "Update".

This process was built to work whatever is start step and can be run and rerun several times with no risks.

Other repository

A CVS repository for non officials modules is also available on Sourceforge:

:ext:youlogin@dolibarr.cvs.sourceforge.net:/cvsroot/dolibarr

Start a development

Read first completely the Developer documentation to know all rules a developer must respect. You can also read following FAQ.

How to create a new skin

For this, see page Skins

How to develop my own menu system

For this, see page Menus system

How to develop my own feature module

For this, see page Module development

How to add/complete a translation

For this, see page Translator documentation

Change my numbering system after start

If the new numbering system does not conflict with the old one, to change the numbering rule, just go on menu Setup - Modules - Invoice setup and choose the new numbering rule in the list. If the new rule can crete conflicts with old one, it will be necessary to rename old existing references. This can be do by a SQL request. For example, to go from numbering module Jupiter (FYYYYMM99) to Terre (FAYYMM-999), you can run the folloing request:

update llx_facture set facnumber=concat('FA',substr(facnumber,4,4),'-',substr(facnumber,8))
where facnumber like 'F%' and facnumber not like 'FA%';

For example, to rename references from modele FAYYMM999 to Terre (FAYYMM-999), you can ru the following request:

update llx_facture set facnumber=concat('FA',substr(facnumber,3,4),'-',substr(CONCAT('0000',substr(facnumber,7)),-4))
where facnumber like 'FA%' and facnumber not like '%-%';

Submit a patch, work and help on Dolibarr development

• With a CVS write access

For the moment, CVS write access are restricted (number of commits is already active). If you have this access, you can use it, but if and only if you use it to commit changes you are granted to with your developer grade (See FAQ Developer - How to be an official developer for information on different grades). If you don't have CVS access (your grade must be Soldier or Fighter), it is necessary to follow the following steps...

• With no CVS write access

With no write CVS access (with no savannah developer account), it is necessary to provide a patch file by mail.

For all OS:

This is the best method to work to build such a patch file:

- First, you must have a directory containing last reference version of Dolibarr (the result of a CVS update or simply the files resulting of uncompressing a Dolibarr .tgz snapshot). We will cal this directory old_dir. You can get this snapshot for current developed version on Dolibarr official web site in download area - development version.

- Then, you must have a second directory, from same source, that will contains Dolibarr directories, in which you will make all you files. We will call this directory new_dir.

To build the patch file, you must launch the diff command (available on all Linux, provided with cygwin under Windows) with the following command:

diff -Naur --exclude=CVS --exclude="*.patch" --exclude=".#*" --exclude="*~" --exclude="*.rej"
     --exclude="*.orig" --exclude="*.bak" --exclude=conf.php --exclude=documents  
     old_dir new_dir  > mypatch.patch

A ksh script to run this command is available in directory build/patch. Send your patch on Dev Mailing List to the address dolibarr-dev@nongnu.org (after subscribing to it). Inclusion of your patch is however not guaranted, no more than delay. But if patch is realized strictly with using this process, there is a very important probability (near 100%) that it will be at least "tested" (if patch is not done this way, chance are simply null).

For Windows:

Page waiting for translation. To translate, create an account, go back and clic on "Modify". Page en attente de traduction. Pour traduire, créez un compte, revenez et cliquez sur "Modifier". Página a traducir. Para traducirla, cree una cuenta, vuelva a la página y haga clic en "editar". Pagina da tradurre. Per tradurla, crea un utente, torna indietro e clicca su "modifica". Página a aguardar por tradução. Para traduzir, crie uma conta, volte atrás e clique em "Modificar". Seite wartet auf Übersetzung. Um Übersetzung zu erstellen, richte einen Account ein, geh zurück und klicke auf "bearbeiten". 页面等待翻译。若要翻译本页，先创建一个帐户、登录并返回本页后单击“编辑”。

If you work on Windows, another method (not so nice than previous) is also possible. Install the open source compare tools called Winmerge (this tool is able to build patch with format diff -Naur). Then compare with WinMerge the reference file and modified file and choose in menu "Tools - Generate patch". Add an output filename like "mypatch.patch", click on box "Append" and hcoose option "Format Unified". Then click on "Ok". Eventually restart for each modified file. Finally, you will get a file mypatch.patch that contains all changes with goode format.

Apply a patch Si votre patch n'a pas encore été appliqué, mais que vous souhaitez de votre coté l'appliquer sur votre serveur linux fraichement mis à jour depuis la CVS, cela est possible grace à l'utilitaire patch. En admettant que vous avez créé votre patch à partir du répertoire htdocs de votre copie locale du cvs modifiée par vos soins, et que vous avez envoyé votre patch (monfichier.patch) sur le serveur dans le dossier patchs situé au meme niveau que votre dossier htdocs distant, la commande suivante devrait faire l'affaire (executée depuis le dossier patchs):

patch -u -p0 -d ../htdocs < monfichier.patch

Pour information: -p0 permet d'utiliser le chemin entier tel que mentionné dans le fichier de patch (-pn en retire les n premiers niveau de l'arborescence) -d permet de préciser le chemin relatif vers le dossier htdocs à patcher. < permet de donner le chemin vers le fichier source à utiliser (le patch en mode unifié) -u permet de préciser que le patch est en mode unifié

How to package and deploy a module

See page Module development

How to be an official developer

In the galaxy of the project Dolibarr, there are several stakeholders at different levels / grades. The number of developers is important and contributions and changes, for any project that wants to reach a certain level of quality, must be controlled and validated (both for functional needs and for code). For this reason, the write access on the source (CVS) is limited and governed by an organization that is described in the following. Each developer has a grade depending on seniority and the past. The level of authorization of a person on the project increases with the stages of promotion in grade.

The course of a Dolibarr developer passes through these steps, which are classified by a title familiar to fans of science fiction. Here are the steps. It is important to understand that this organization has the sole purpose of improving the quality of Dolibarr and it is necessary that it is rigorously used. So do not be offended if, as a developer, you can not have a CVS write access for some time.

The ranks of contributors to the project Dolibarr are:

* Soldier

The first thing that a person willing to help is to be familiar with the rules and standards developments. Reading the Developer documentation, you have shown sufficient willingness to become automatically Soldier (grade level Soldier). And just read is not the easiest ...

This grade is obtained without validation higher. It is a grade of principle, to start.

Due to the nature of this level, it is not possible to establish a list of all Dolibarr actors with this grade (list always changing and too long).

* Fighter

The next step is to submit your first patch, starting with simple, on the dev Mailing List (see Developer FAQ for the procedure) or on the forum (Preferred Mailing List).

At your first bid accepted (included in CVS by an Admiral, Jedi or Yoda), you automatically enter into the family of Fighters of the Dolibarr alliance.

The number of hunters is not limited. The more we are, the more we will be strong. The hunters are the main force of the alliance Dolibarr.

A list of Dolibarr contributors with this grade is available on page Category:Chasseur

* Z-6PO

If you are fluent in a language not or poorly translated into Dolibarr, a Jedi or Yoda will give you CVS access so you can make commits to the CVS of the project. But commits must be limited to changes for translations purposes. This grade can be obtained quickly enough. Just ask it on mailing list.

A list of Dolibarr contributors with this grade is available on page Category:Z-6PO

* Admiral

Only after a variable time (which can be very long) to the rank of a Fighter, and many patches of suitable quality had been sent, a Yoda in place allows you to make CVS commits extended for cause of any patch. You have become a Admiral of the alliance Dolibarr.

This title can't be asked, it is obtained by a decision or proposal of a Jedi or Yoda who believes that you have submitted enough patch to be a serious Admiral. An Admiral CVS access, however, must be used to commit translations or bug fixes reported on Savannah or forum (such as personal fixes or fixes submitted by a Fighter). So all CVS commits made must necessarily include in the description (the commit log field), the issue of Savannah bug corrected or the title of the forum message indicating the problem. Only a translation escapes this constraint (no restrictions for translations). Failure to observe this constraint may lead to downgrade to the rank of Fighter. For submission of new features, an Admiral must necessarily proceed on the principle of patches sent to the ML.

Obtaining the rank of Admiral is as rare as limited. Dolibarr quality can not be achieved without a limited number of Admirals, but this is still compatible with having a very high number of developers (Fighters), contributing through patches.

A list of Dolibarr contributors with this grade is available on page Category:Amiral

* Jedi

This is even after a variable time (probably the longest of all) to the rank of Admiral, and the quality of the patch that was sent is satisfactory, that a Yoda will tell you that you are authorized to perform commits without restrictions, included new features, however you will still have to explain to all Yoda what you want to do to give back a "go". You will then become a Jedi. There may be temporary restrictions on commits, defined by a Yoda, for example due to a close release.

This title can't be asked, it is obtained by a proposal of another Jedi or by a Yoda.

This privilege is exceptional. Dolibarr quality can not be achieved without a limited number of Jedi, but this is not compatible with a high number developers (Fighters) contributing with patches.

A list of Dolibarr contributors with this grade is available on page Category:Jedi

* Yoda

There is about 1 to 5 Yoda. It's the overall management of project development. This ranking is obtained by inheritance or vote, for example it can be after a vote organized by a Yoda making retirement.

A list of Dolibarr contributors with this grade is available on page Category:Yoda

* And Darth Vader?

There is some parasites people that pollute the forum or mailing-list with aggressive messages, which slows the development of Dolibarr rather than offering constructive criticism to help improve. Some are very strong bad liver and bad tone. Such people are Darth Vaders. Fortunately, statistically, there is only one or two Dark Vador per year ...

Current team

See page Dolibarr Project to know list of current people that work on Dolibarr, with their current grade.

How to be informed on what happens on Dolibarr project ?

See page FAQ How to be informed about Dolibarr project ?