Dolibarr roadmap - Foundation vision

[agarcina]

Does Dolibarr foundation has a road map?
Which major enhacements will have Dolibarr?
Is it going to develop better Dolidroid?
What is the vision of Dolibarr?
Thanks.

[ksar]

Hi,

There is no real “roadmap”
You have some information here : https://wiki.dolibarr.org/index.php/Category:RoadMap
and there : https://github.com/Dolibarr/dolibarr/issues?q=is%3Aopen+is%3Aissue+label%3A"Priority+Top+Strategic"
Dolidroid is not part of the fundation, it is developp by an external compagny

[JoeyJoystick]

Hi ksar,

I think the question asked is a very important question. Dolibarr is open source and free. In order for more companies to embrace dolibarr they will at least need to know where this is heading.

Now please do not get me wrong. Dolibarr is an amazing development. I think it is a great package. However, there is a couple of things I would like to point out. Please look at it the way I have intended it. Constructive criticism. I am in no way criticizing anyone personally. Here some concerns.

• I miss consistency at times. By this I mean that things are done differently in different modules, while this could have been done in exactly the same manner. If the same it will make it easier for the end users to master the use of Dolibarr. This is not a bug. It is merely shows some shortcoming of how the Dolibarr project is being managed.
• I think by further developing Dolibarr it will get more and more complicated. This in turn will result in difficulties when bugs or security issues are found.
• I think the general approach should be reconsidered. I am not saying it is wrong and it should be changed. What I am saying that there needs to be an on-going discussion regarding this. Certain aspects of Dolibarr will sooner or later need to be overhauled. The longer you wait the more difficult it will be to achieve this.
• I noticed that some data in some modules is stored separately. The result of this is that when the main data is updated that the secondary data, which is the same, will not be updated. I have seen this on a few occasions.
• I notice in Dolibarr that we talk about members and contacts. Surprisingly, these are also stored in different tables in SQL. I strongly believe that this approach is flawed. I think there is 1 single table with people. And people can be marked as members and can be marked as contacts. People move around to often. This approach would allow for a lot more flexibility. People come and go. People move from one company to an other company. People may be involved with more than 1 company. Keep them together in 1 place is better, easier and helps keeping data consistent.
• The thought process should be applied to entities. Your own company is an entity, So is a supplier and a customer. Consultancy. NGOs. Government institutions.
• The possibilities for the following are already implemented, albeit in a limited manner. It should be possible to link all entities and persons. You have head offices and branch offices. Regional and local offices. It is not easy right now to bring this kind of structure into your data.
• My biggest concern is security. Now I am not in a position to say that Dolibarr is not secure. I have no reason to say that. But security should also be on top of anybody’s list I think. Some of the following has been implemented in part. But here I go anyways. There should be both a horizontal and vertical approach to security. With horizontal I mean which modules and which part of a module do people have access to. Vertical refers to the amount of dat you have access to based on the security level given to you. This could be a level from 0-100 as I have seen in other CRM packages. People can be grouped according to function and department. People can be assigned different groups. And all the rights are assigned to groups and not to people.
• There is very good help available when you are stuck with Dolibarr. However, the process works if you have an issue at hand. I while ago I had made a list of several dozen items that were wrong. Some bugs. Some aesthetics. I approached a board member and asked if I could just send an email with this document attached so you guys can take a look at it. I am obviously NOT going to open 30 odd cases in the help section. Than again, I was merely trying to help. It was explained to me that since you work decentralized this will not work because different people have different responsibilities. As a result this information has never been transferred to Dolibarr. I think that is a shame. 2 know more than 1 and 3 know more than 2. I am not saying I am right about all of the above, or the email I intended to send to you, but ignoring and dismissing it is the wrong approach for such a large project.

And now my biggest concern is that if the general approach of Dolibarr does not change, there will be a time when people look back and realize that what they have is a mere shadow of what they had and wished to accomplish when they first started the Dolibarr project.

Again, please take all tis as intended. It is not personal. It is supposed to be constructive. All I am trying to achieve with this is that it is being looked at and being thought about.

Best Regards,

Joey

EDIT: And I forgot to mention the following. Document Control. The size limit of a few MB on a doc is unacceptable in 2020. You want to be able to run paper free. This needs to be increased to a several hundred MB.

• Documents are not limited to po, quotations and sales orders. You want a products service manuals, maintenance manuals, user manuals, warranty cards. Catalogues and brochures all stored in SQL. You guy sneed to weight the pros and cons of how you approach that, but for the time being I think this a serious limitations of Dolibarr. Right now a reference to these documents is stored in SQL with the actual document stored on your HDD. (ok, server.) All documents can also be stored in binary directly in SQL.I know this is being done by others. I worked with it and if the infrastructure is ok this works fine from what I remember. I do not recall annoying speed limitations because of an overloaded server, or network constraints. This was in a company with 400-2000 users of whom about 150 had permanent acces and used it on a daily basis.

[c241]

agree with you. I accepted a project which use Dolibarr to dev a module, but I would like Symfony

[Best]

I like your opinion. I think I will make a dif for dolibarr

[eldy]

@JoeyJoystick

Hi ksar,

I think the question asked is a very important question. Dolibarr is open source and free. In order for more companies to embrace dolibarr they will at least need to know where this is heading.

Now please do not get me wrong. Dolibarr is an amazing development. I think it is a great package. However, there is a couple of things I would like to point out. Please look at it the way I have intended it. Constructive criticism. I am in no way criticizing anyone personally. Here some concerns.

• I miss consistency at times. By this I mean that things are done differently in different modules, while this could have been done in exactly the same manner. If the same it will make it easier for the end users to master the use of Dolibarr. This is not a bug. It is merely shows some shortcoming of how the Dolibarr project is being managed.

=> It is a point of view. A lot of users says they like Dolibarr because of its consistency in features. Your feedback means we must do more. Creating github issues with the example and concrete case of enhancement may help (1 ticket = 1 suggested enhancement). Note that github issue must be concrete with example and not be a general feedback.

• I think by further developing Dolibarr it will get more and more complicated. This in turn will result in difficulties when bugs or security issues are found.

=> Yes. that’s why I take care in how the code is integrated and i am strict in code quality. Currently, after 17 years of changing code on softwares, Dolibarr is still the software with the most easy way to fix bugs I have never worked on. So for the moment i am not frightened by this point. But this is a danger.

• I think the general approach should be reconsidered. I am not saying it is wrong and it should be changed. What I am saying that there needs to be an on-going discussion regarding this. Certain aspects of Dolibarr will sooner or later need to be overhauled. The longer you wait the more difficult it will be to achieve this.

=> Each point must be addressed one by one, and Github issue are dedicated to that. Github will open a new space for this called “Github discussion” that may be a better place. This features will be tested to see if we can use it soon.

• I noticed that some data in some modules is stored separately. The result of this is that when the main data is updated that the secondary data, which is the same, will not be updated. I have seen this on a few occasions.
• I notice in Dolibarr that we talk about members and contacts. Surprisingly, these are also stored in different tables in SQL. I strongly believe that this approach is flawed. I think there is 1 single table with people. And people can be marked as members and can be marked as contacts. People move around to often. This approach would allow for a lot more flexibility. People come and go. People move from one company to an other company. People may be involved with more than 1 company. Keep them together in 1 place is better, easier and helps keeping data consistent.

=> For the moment we did not identified data that are duplicated in different tables when they should not. May be for your use case, a thirdparty is same than a member of a foundation but this is not always true. It depends on your workflow on the features you decide to enable.
You may have 10 contact/address for only on company. Also storing an alternative address (lawyer service, eternal bookkeeper of company) into same table than the company has no sense. Except name, address, zip and phone, 90% of fields differs and have no sense for an alternative address. This is same for the foundation module. You may have a hundred of subscriber to the foundation and have thousands of third parties. They are not used for same features with not the same properties. There is some common parts and there is a sync for this common part (in fact, only the address) when a member is also a thirdparty, but this is very small part of information.

• The thought process should be applied to entities. Your own company is an entity, So is a supplier and a customer. Consultancy. NGOs. Government institutions.

=> That is the reason why your own company is the same object in the code than other companies. However, the workflow to edit your own company information is rarely the same than workflow to edit your customers or suppliers. It is different people, with different permission, in different workflow. Currently, we have never received any requests by any users to make this differently. But this does not means it is good.

• The possibilities for the following are already implemented, albeit in a limited manner. It should be possible to link all entities and persons. You have head offices and branch offices. Regional and local offices. It is not easy right now to bring this kind of structure into your data.

=> Yes, the reason is that such a feature is not yet implemented into the core. External module may address that as there is so many different use case and way to implement this. But such feature may appears in future. A work has been started with a module “Human Resource” that implement “department” to manage Head office and branches but this is not yet available. Several workaround exists (using tags, using external module, using extrafields).

• My biggest concern is security. Now I am not in a position to say that Dolibarr is not secure. I have no reason to say that. But security should also be on top of anybody’s list I think. Some of the following has been implemented in part. But here I go anyways. There should be both a horizontal and vertical approach to security. With horizontal I mean which modules and which part of a module do people have access to. Vertical refers to the amount of dat you have access to based on the security level given to you. This could be a level from 0-100 as I have seen in other CRM packages. People can be grouped according to function and department. People can be assigned different groups. And all the rights are assigned to groups and not to people.

=> About technical security, the delay of fixing security report is around 5 days on Dolibarr project. So i think we are very reactive about security reports. Also the project publish a page to decribe all what have been done into code to fight against any security thread:
Security information - Dolibarr ERP CRM Wiki

=> About vertical permissions, currently, there is no system for vertical permissions in the core. The reason is that there is not a lot of demand, not enough to have this currently into the core. And the workflow and the need we want to have once a vertical protection is required, may be completely different. For this reason, such feature is currently adressed by external modules or by integrators that are at a better place to implement an addon to math the need. But this may change according to coming contributions if we receive an implementatin that is not a “gaz factory”. Note that this is also true for any point.

• There is very good help available when you are stuck with Dolibarr. However, the process works if you have an issue at hand. I while ago I had made a list of several dozen items that were wrong. Some bugs. Some aesthetics. I approached a board member and asked if I could just send an email with this document attached so you guys can take a look at it. I am obviously NOT going to open 30 odd cases in the help section. Than again, I was merely trying to help. It was explained to me that since you work decentralized this will not work because different people have different responsibilities. As a result this information has never been transferred to Dolibarr. I think that is a shame. 2 know more than 1 and 3 know more than 2. I am not saying I am right about all of the above, or the email I intended to send to you, but ignoring and dismissing it is the wrong approach for such a large project.

=> An email is not a good way to work in a community. How are informed all the community (there is several thousands of people working in dev, translation, doc, …). Also how can everybody exchange on this ? It is also not possible to exchange by email. How can we filter duplicate topics to avoid to received duplicate email. For this reason an issue ticket is always better. Luck to receive an answer to emails speaking about a bug or a feature request are near 0. To have the best chance that an information reach the target the recommended method must be used. And email is surely not the recommended method for bug or code enhancement discussions.

And now my biggest concern is that if the general approach of Dolibarr does not change, there will be a time when people look back and realize that what they have is a mere shadow of what they had and wished to accomplish when they first started the Dolibarr project.

=> Currently we are experiencing the opposite. More and more people are joining the project and most people are happy on how the project evolve. We also have a very low turnover compared to other projects. But we will never reach 100% of statisfaction and 0% of turnover.

Again, please take all tis as intended. It is not personal. It is supposed to be constructive. All I am trying to achieve with this is that it is being looked at and being thought about.

=> Not that your point are very “generic” and very abstract". It is difficult for someone to answer such a post. To increase your chance, i recommend :

• Report code enhancement suggestion on github issue
• Use 1 ticket for each point.
• Be patient
  Don’t forget that, if we includes all users, we are probably several hunderd of thousands to use and to have feedbacks on Dolibarr, you can’t hope to have a personalized answer for each of your point if not

Best Regards,

Joey

EDIT: And I forgot to mention the following. Document Control. The size limit of a few MB on a doc is unacceptable in 2020. You want to be able to run paper free. This needs to be increased to a several hundred MB.

=> There is no limit in size of doc in Dolibarr. Only the system administrator of the infrastructure can set such limits. You can reach Giga bytes and more if your infrastrcuture is correctly sized for this.

• Documents are not limited to po, quotations and sales orders. You want a products service manuals, maintenance manuals, user manuals, warranty cards. Catalogues and brochures all stored in SQL. You guy sneed to weight the pros and cons of how you approach that, but for the time being I think this a serious limitations of Dolibarr. Right now a reference to these documents is stored in SQL with the actual document stored on your HDD. (ok, server.) All documents can also be stored in binary directly in SQL.I know this is being done by others. I worked with it and if the infrastructure is ok this works fine from what I remember. I do not recall annoying speed limitations because of an overloaded server, or network constraints. This was in a company with 400-2000 users of whom about 150 had permanent acces and used it on a daily basis.

[JoeyJoystick]

Hi Eldy,

Thank you very much for your elaborate response.

I agree with much of what you say in your response. Especially that it will always be impossible to please everybody…

Very happy to hear your comments regarding security.

I will try to be a little more patient next time…

Thanks and continue the great work.

Joey

[altatof]

Hello, i will also add my 2 cents about the “security” point; i have developed an external module for managing permissions on product (by user or group for product or category of product) but i think i’ve made 1 or maybe 2 sales of this module.
I was thinking it will become a best-seller and that i will do the same for thirdparties and maybe other elements, but it was a real flop !

What i mean is that Dolibarr can do the most complexity, but is here to satisfy the most people.
And do not forget that it is free and the global “economical” model that made Dolibarr as great after more than 15 years is that the one who wants more from it pays for it

It might be a brutal conclusion but we are on the international forum speaking english and “business is business” (in France we say “pas de bras, pas de chocolat”) :