Dear Dolibarr community,
This is my first post so i’ll introduce myself a little bit.
We’re glad to use Dolibarr and its many features that comes for free.
Actually, this message can’t thank you enough for all the good work you did.
As a user and developer, there are plenty of functions i’m still discovering as i’m using your product.
How long have we been using Dolibarr ?
Our company is using it for two years. But i’m new here and using it myself for 2 months.
About the features we use
We mostly create customers, suppliers (some are both), proposals, projects, commands, contracts, invoices.
I’ll give some more details later.
About the version we use
We use Alpha 3.2
So what ?
This is all good but there’s always a but.
My company asked me to make one, then two, then three, then X modifications + more features + more bug correction.
About our Architecture
We used to have only one Dolibarr instance installed on our linux server.
I quickly installed a subversion system (SVN) so i can best figure out each code modification.
Then i installed Dolibarr on my computer so i can develop new code without impacting server version.
Finally, i installed Redmine so i can manage better requests/bug/corrections and browse repository history in a cool way.
About our Workflow
Here it is:
[ol]
[li]Some of our team mate suggest a new feature/find out a bug/ask for assistance[/li]
[li]I create a new ticket in Redmine to write down this demand[/li]
[li]If ever needed, i develop the extra feature/bug correction on my local computer[/li]
[li]After i tested everything is ok from my computer i do commit my modified files to our SVN server[/li]
[li]I ssh to our dolibarr server and make a svn update so that my previous commit are spread to our team users.[/li]
[li]I close the redmine ticket opened in step 2/ with adding notes accordingly.[/li][/ol]
So what (number 2) ?
I just reached Redmine ticket number #70 and realized something was wrong with this workflow.
Our Dolibarr code is getting more and more customized to our company’s needs but we can’t benefit from community improvements anymore. Yes that is bad and quite opposite to open source philosophy.
We are working from within a closed bottle and there’s a hammer hanging nearby.
Lately, i patched a bug in htdocs/commande/stats/index.php (it was missing “mode=supplier” parameter in the query string after filtering by username). Actually it just needed to add an hidden field in the form).
I was curious enough to check this gotcha in the latest development code, and was ready to tell the comunity about it if ever it was not fixed yet.
I didn’t know Git, nor how to contact Dolibarr community, so it took me two days to subscribe the right mailing list, subscribe the forums, subscribe Git, subscribe Gravatar, read some mailing list entries, forum entries, and to read about Git…
About the patch on “htdocs/commande/stats/index.php”, i found out it was already fixed one month ago by Laurent Destailleur on the develop branch.
Not only i realized i was taking a wrong approach with my “local SVN development workflow” but i decided to change things, really. Wouldn’t it be cool if i can get the latest bug fixes ? Wouldn’t it be a time saver instead of trying to fix what other already did ? Wouldn’t it be cool to get more features and improvements with just fetching and merging with official “develop” branch ?
I both felt in love with GitHub, and felt bad not knowing/using it for my entire developer’s existence.
I’m now excited to fork the Dolibarr’s develop branch, clone that on my local computer and make it working with our own database + config files. I will surely use GitHub as well to follow other projects and to make my own.
Back to our Dolibarr’s approach. It’ll be challenging, but i plan to start over:
[ul]
[li]step 1/ forking and cloning the “develop” branch.[/li]
[li]step 2/ Getting this clone to work with our own database / config files.[/li]
[li]step 3/ adding our approx 50 hacks gradually[/li]
[li]step 4/ fetching and merging with GitHub “develop” branch from time to time to stay up to date with communiy[/li][/ul]
This beeing said,
I would love some of our hacks to be used and merged with the “develop” branch so that is can benefit the whole community. This put one to his best (knowing more will use it).
But i doubt it to be realistic for several reasons:
Our hacks involves adding vars and functions to existing classes. As so fields to existing tables and brand new tables, new menus…
I am conscious that if everyone “hack” the code, add fields and tables, it will results in unstable crashy-sloppy-like product difficult to maintain. It’s all but what we want.
The extra features we coded so far include:
- a new page showing a synthetic view of all commands through one big table
- a new page showing a synthetic view of all projects through one big table
- being able to set a command status back to draft through a button
- auto-fill some fields to simplify invoice creation from a command (like: project field)
- new command attribute: “budget type” (can be: “material”, “engineering”, “renting”, “labor”…)
- add a synthetic table in each “projet/fiche.php” view showing various useful informations relative to sub-commands nad invoices
- can export synthetic view of all projects/commands through a neat Excel file
- bug fix relative to specific user in the stats numbers (SQL fix)
- supplier order: can now receive partial delivery. (command status added for that)
- bug fix relative to rounding total amount in a command (some cents were missing)
- bug fix relative to auto-complete for society name during invoice creation
- bug fix relative to “libelle” invoice attribute being blank (due to improper “label” class var)
- some cleaning in the log file (some irrelevant informations were logged forever)
- give more choices in the society popup menu after cloning a proposal
- create contracts for supplier (the same way as with contracts for customers)
- new attribute for “order supplier”: so we can set to 0 the “amount to be billed”
- a new left menu to show only “my supplier order” (filtering by username wasn’t working properly)
- new attribute for “projects”: can be “customer” or “prospect”
- Add a “main contact” when creating a project
- Add an “Accuse de reception” to appear on pdf invoices
- Add more payment methods and their corresponding text to be printed on the pdf
- possibility to have sub-projects in a project
And there’s more to come:
- Link with Ciel Compta through export/import
- Different workflow to validate a command, involving different people with different roles.
- More views about bills and order. What’s paid, what’s left to be paid, and so on…
- more to come i don’t know yet
During those coding exercices, i greatly appreciated:
- database model: table names are expressive. It’s easy to figure out where is the info we’re looking for.
- database convention: “rowid” and “fk_” rules !
- no framework: some argue it’s a cons, but for me it’s a pro: more lightweight, more control, no learning curve.
- control/view in the same file: i found it very useful to quickly move from top to bottom without switching files.
- directory tree is made clear thanks to each modules having their own class directory
- “fetch” method is very convenient when using an object, we magically get all its attribute for free.
- html form helpers are great when designing new forms
- PHP Excel is a good choice to read / render Excel document
- user permissions has great details and is made simple to test through $user global var
- $langs and $db are great global var
- overall code is clean, robust and well structured. Easy to patch.
Creation of a new project (new features are in red square)
Pièces jointes :
- sipartech_logo.png (9.19 KB)
