[RELEASE] CustomFields module

Developing for Dolibarr
1

CustomFields module for Dolibarr

Downloads

=> CustomFields PRO EDITION V3

CustomFields Pro edition v3 is available for all versions of Dolibarr from 3.1 up to the latest (currently 3.3-alpha), you can buy it here:

http://www.customfields.org

Online demo:
http://customfields.org/demo/htdocs/index.php

CustomFields Pro contains all the features of CustomFields Free, but with many other more advanced features such as functions overloading. For a full comparison, you can consult the comparison chart here:

http://www.customfields.org/website/en/#comparison-chart

Note: Fields created with older versions of CustomFields and the Free version are fully compatible with the Pro version, you just need to delete all files CustomFields before copying the files from the Pro version (everything is explained in the file INSTALL.txt included in the archive, and also on the wiki). You will keep all your custom fields and data associated intact when upgrading.

=> CustomFields FREE EDITION V2

CustomFields Free edition is an open source version covered by the GPLv2 license and available for free (and always will be!). It works for all versions of Dolibarr from version 3.1 up to the latest.

= To download CustomFields Free edition for Dolibarr >= 3.3:
https://github.com/lrq3000/dolibarr_customfields/zipball/3.3
or
http://www.dolistore.com/other/221-Custom-Fields.html

= To download CustomFields Free edition for Dolibarr >= 3.2:

https://github.com/lrq3000/dolibarr_customfields/zipball/3.2
or
http://www.dolistore.com/other/98-Custom-Fields-for-Dolibarr-3-2.html

= To download CustomFields Free edition for Dolibarr 3.1.1:

https://github.com/lrq3000/dolibarr_customfields/zipball/3.1
or
http://www.dolistore.com/other/174-Custom-Fields-for-Dolibarr-3-1.html

Note: it is [b]strongly recommended to update your version of CustomFields if it is below 2.11[/ b] for the latest new features are critical.

Documentation

Documentation for the Free edition of the module can be found directly inside the archive files, in the file README-CF.txt

A full documentation of the Pro version of the module is available online on the wiki:

User documentation:

Developper documentation:

Example cases:

The rest of the post is old news and is kept here for history, you can just jump to the wiki and begin using the module.

Description

I here present you a module that my company created to be able to create and manage automatically/semi-automatically user-made custom fields. I here offer it freely and in opensource as a contribution back to the Dolibarr project.

My goal was to create a module that would semi-automate the creation of customfields, but fully automate the management of fields, even the ones that would be customized by the user (custom type, constraints or views or other complex sql), and that would be easy to integrate into the heterogenous nature of Dolibarr and into virtually any other module with little effort. I was not very satisfied with the currently similar implementation in the extraFields class, because it is not very generic (made for one module as of now and is very tedious to adapt to other modules). I wanted something more generic, easily adaptable to any module using a sql table to store its datas (a minimum of copy/paste to do), and to rely a maximum on SQL technology rather than php: I wanted my module to directly create a valid SQL structures, with real SQL fields, so that it can theoretically create and handle any SQL field type, even the one that were not thought by the devs. generic functions provided for programmers like fetchAny or fetchReferences.

The CustomFields module I present here can be fully adapted to almost any module in 4 to 7 steps (instructions provided in the Readme-CF.txt file).

You can find attached to this post the latest standalone release of the module (modCustomFields_v1-1-1). For the very latest release, you can find it merged into my Dolibarr github repository:

https://github.com/lrq3000/dolibarr

A few screenshots:

FEATURES:
- Natively support the modules: Invoices, Propales and Products/Services.

- Full multilanguage support (french and english for now, but you can easily translate to other languages using the same system as Dolibarr language files):
* multilanguage in the administration gui
* multilanguage user-defined custom fields labels
* AND multilanguage custom fields values (eg: yes/no select box can be translated to any language, same for enum user defined values). You can translate the values of your dropdown boxes!

- 6 natively supported fields types :
* Textbox
* Areabox
* YesNoBox
* TrueFalseBox
* DropdownBox (your own options)
* Constrained (link to other tables)
* Other (custom type)

The last one is not a native support but permits you to easily set any SQL data type that is not yet implemented, but it will be managed as best as possible by the module (by default if itā€™s unknown it will be shown as a textbox).

It is easy too to add a native support for a new custom field type and manage the way it has to be printed on screen.

- Custom sql statements to create complex fields : these custom sql statements will be executed after the creation/edition of the custom field definition.

- Portable to any version of Dolibarr (in theory - as long as triggers are implemented)

- Seamlessly integrate into Dolibarr (seamlessly integrate into core functions and no change in the coding habits of Dolibarrā€™s devs).

- Fully automated management of the customfields in the database and via triggers.

- Extensible to any module, be it core module or third-party user-made module (instructions provided in the README-CF.txt inside).

- Linked fields: Auto-detection and auto management of constraints (automatically find the primary key and choose the same data type and size) and auto management of their printing and edition (show them as a dropdown box).

You can even select the right field column to show to the user from the table.

Eg: if you want to link to the Dolibarrā€™s users, select Constraint ā€œllx_usersā€. It will then show the rowid of the user. Now if you want to show the userā€™s name instead of the rowid, just prefix ā€œname_ā€ to your custom fieldā€™s name (like ā€œname_refā€) and CustomFields will automatically fetch and show the userā€™s names!

- Can define different custom fields PER module (you can have different custom fields for each module)

- Totally integrated into the generation of PDF and ODT (usable just as tags - you can even access linked records values of a constrained field, more inside the readme-technical).

- Elegant presentation in datasheet.

- Supports all classic functions of a standard field: creation, edition, cloning, etc.

- Clean: do not interfer with the normal functionning of Dolibarr, everything is separated. You can just delete the customfields and it will never do anything wrong with your Dolibarr install or your other datas.

- Develop your own modules via CustomFields: CF provides many methods to automatically manage the inputs of a user and access custom fields values from anywhere in the code (from Dolibarrā€™s core to your own module!), and even a few generic functions to issue any SQL request and help to manage them.

- Code is very easy to edit/customize/reuse/port (fully commented and modular architecture, and no duplicates functionnalities).

- Free and open source: free to use, redistribute and edit to your needs!

- Use of strict SQL standards, so it should work for any database following the minimum standards requirement (tested on MySQL, probably works for PostGreSQL and SQLite).

More will come around the Dolibarr project with the final release like automatic attachment of external PDFs in PDF.

PiĆØces jointes :

1 Like
2

Update: final release of the CustomFields module. Will soon be sent to the Dolibarr stopre.

@eldy
Iā€™m just thinking about the fact that Dolibarr seems to be in a constant evolution cycle at this time. Would it be possible to integrate CustomFields into the Dolibarrā€™s package if you deem it appropriate?

I know there is already an ExtraFields class, but as of now the CustomFields module is much more generic and has much more functionnalities (mainly the linked fields) and is much more proper since it mainly relies on SQL to manage the fields. Already 3 modules are natively supported, and it can easily and quickly be ported to others (4 to 7 steps are required, they are all detailed in the readme). And CustomFields does not conflict with ExtraFields, so they can colive.

This would avoid the users to port the plugin to each version of Dolibarr each time a new release comes out.

I will provide a full changelog, and I can fork the dolibarr-3.1.0-beta2 (on which it has been made) so that you can easily merge it back to the current branch.

1 Like
3

I will have a look later to know if this will be part of standard code of external module (policy for the moment is to have ā€œbasicā€ function into standard code and more enhanced into external modules).
But what is sure is that it wonā€™t be into 3.1 because new features are frozen from 5 month now into 3.1.

4

Ok I understand, anyway itā€™s already made for v3.1.0 (beta2 but I can port the changes to the final release, I donā€™t think too much changed in these files), so itā€™s ok for this release, but the problem arises for future version.

I understand your policy about functions, thatā€™s why I tried to make this module as independant from the core system as possible, but due to the very nature of the functionnalities it provides it cannot totally be cut from the system.

I think that CustomFields could be a nice addition at it provides not only a powerful way for users to meet their requirements, but also it could be used by third-party developpers as a foundation to create their own user-oriented modules since the CustomFields class provides an automatic database management of userā€™s inputs, functions for management and printing, and so the custom fields objects are potentially available anywhere in the Dolibarr code.

The code is free so I leave it to the Dolibarrā€™s project and users as a free contribution. I will create a fork on Github so that it can be merged back easily.

5

Update v1.0.9: fixes quite a few bugs and adds some more methods for devs and an addendum to the readme for devs (how to use CustomFields in your own code).

If you already use an older version of CustomFields, just overwrite the old files with the new ones, it will work flawlessly.

6

Eldy, I absolutely need Dolibarr v3.1.0 beta2 but I canā€™t find it anymore anywhere on the web. Could you provide me a link please?

/EDIT:
No finally itā€™s ok, I donā€™t need the beta2 anymore, I manually merged with the current main branch from github and everything ran smooth. I will soon post a Github fork with some other enhancements (like a php script to backup mysql database without needing the mysqldump binary - perfect for shared hosting).

7

Update: now on Github: https://github.com/lrq3000/dolibarr

I have made a few minor updates to the CustomFields module, I ported it to the latest main branch and I added a few bugfixes and features I have made for my own environment.

@eldy, I did a pull request with a more detailed summary of my changes, and I separated each changes into different commits so that you can easily cherry pick what you want (of course Iā€™d be glad if you pick it all :wink: ).

Enjoy.

8

Itā€™s really awesome!!! Gives more versatility to this fantastic software. Thanks a lot for this module,it really works for my needs!!
Reggards.

9

Latest version of CustomFields for Dolibarr >= 3.2.0 available now on my github:

https://github.com/lrq3000/dolibarr

It uses the new hooks system, so thereā€™s no more any conflict with the core files of Dolibarr.

10

There is now a new release v1.1.3 with backported changes from v1.2.x for Dolibarr v3.1.x

Please be aware that this is a test release, I didnā€™t test it myself so it may be buggy, but if you try it please report if it works ok (it should from what I saw in the code).

11

Is there somewhere a zip for that module I can test ?

12

eldy wrote:

Yes, for v1.1.3 for Dolibarr v 3.1.x it is attached to the first post of this thread.

For v1.2.6 for Dolibarr v3.2.x it is on my github, branch develop2 (not develop, itā€™s the old version unported to the latest changes of Dolibarr) and thereā€™s also a pull request that contains all the diffs on Dolibarr main github.

13

This may be the best module for DB I have seen yet, however I would like to inquire if there is a way to import the custom fields (for products) that we created along with the regular fields. I can try to import, but I do not see anyway to match fields for custom data types.

14

@tkj365: what do you mean by ā€œimportā€? If you mean to use the import module to import data, no itā€™s not supported by the import module (I didnā€™t even think about it, this may be a feature request for the future).

Anyway, CustomFields simply stores the data in a _customfields table (eg: llx_propales_customfields) and so you can easily import a CSV (excel) file by matching the right columns (just look at the table) and import by using phpMyAdmin or a similar database management software (thereā€™s an import functionality there that supports CSV and other types of files).

This should be pretty easy and straightforward, unless you use constrained fields (because youā€™ll have to lookup in your Dolibarr database to fetch yourself the right ID for the item youā€™re linking, but thatā€™s still possible, just not ergonomic).

Thereā€™s no any other dependency for CustomFields than the _customfields table: the module is only there to manage these tables, everything is self-contained there (and thatā€™s the goal).

15

Just updated from 3.0.1 to 3.1.1 to use CustomFields.

tried teh 1.1.3 version first. Got it to work

But whenever the module is active, it hangs when making a new invoice. (even if no additional line is created).

It does load, but something is slowing it down substantially. Anyone else have this problem>

I tried down-grading to 1.1.1 and itā€™s still doing it. I need to the leave the module off to get regular speed / no hangs.

IS there a config I need to do? I just installed, and enabled the module ā€¦ I didnā€™t go digging behind the scenes.

16

same low speed problem for meā€¦ dont know why.

17

I tried purging through dolibar ā€¦ thinking an old link was holding it up ā€¦ no go.

What version of dolibarr are you on? 3.1.1?

Is it because I didnā€™t set-up the language profile?

I also used 1.1.3 first, then backported to 1.1.1

ā€¦ I used the function in customefields 1.1.3 to build a table for ā€˜contact ordersā€™, and ā€˜contact invoicesā€™.

Contact orders didnā€™t show upā€¦ so I back ported to 1.1.1

Is the hanging because, itā€™s looking for that table? even if I enable no-customfields ā€¦ it starts to get slow as soon as the module is activated in Dolibar setup.

Iā€™m on Apache and php 5.2+

18

Does this look correct?

[code]

llx_commande InnoDB Compact 25 655 16384 0 32768 28 utf8_general_ci

llx_commande_customfields MyISAM Dynamic 1 20 20 281474976710655 12288 2 2012-04-07 01:42:01 utf8_general_ci[/code]

The sql fields made by customfields donā€™t appear similar to any of the other dolibarr fields.

This is viewable through Dolibarr sidebar System Info > Database > Tables

I know the dev is working on the 3.2.0 releases already ā€¦ but it would be amazing to have full speed support for the 3.1.1 stable.

19

Probably a bug into module.
The quality rule for dolibarr modules define that all modules must use the innodb format:
http://wiki.dolibarr.org/index.php/Database_naming_rules

20

Hello,

Please forgive me for the late reply, I intended to update the module a month before but due to a critical crash on my system that caused the loss of all of my data, I had to delay this project.

About the lagging when trying to load a page, try to set the constant MAIN_DISABLE_PDF_AUTOUPDATE to 1 (see the wiki for more infossee the wiki for more infos).

About the InnoDB format, this should be fixed with the latest version v1.1.3 (which is a backport of the branch 3.2.x version). Please try this one, delete all _customfields tables, and use the latest version to recreate the customfields tables so that they should be now using the standard Dolibarr format for tables.

This project is not dead, and I will port it definitely to the latest Dolibarr v3.2.x branch in the following months from now, so stay tuned.