This is in fact quite complicated. To access any field of a product from another module (propales, invoices, etc.), you must first get the product’s id, then fetch the product’s object, and then you can fetch its field, whether standard fields or custom fields. The id is given to you in the PDF template inside the lines loop, and using this code:
$lineid = $object->lines[$i]->rowid;
The manoeuver to fetch the object and retrieve the fields is quite complicated, but it’s feasible.
If you want to avoid the hassle of programming all of this by yourself, I have made a module that does exactly that (allow to access products standard and custom fields from any other module easily) which is called ProductsEasyAccess.
I am the developper of the CustomFields module, so I can answer your question pretty precisely.
I have been trying to implement this feature quite recently among other features, and the short answer is that no, this isn’t possible.
The problem is with the HTML standard: Dolibarr uses tables to display the fields, and tables have a definite number of columns. A field cannot modify that, only the table generator can do that. Thus, a custom field cannot add a column on the fly to stack fields along the line. I have tried some workarounds, but they all ended up to be display quite horribly and destroy the whole table display.
Thus, there’s no way to automate that. Now you can of course manually modify the table’s generation in Dolibarr’s code on a case-per-case basis, by raising the total number of columns the table generate. But as I said, this will break the whole table display, because you will also have to modify how the standard Dolibarr’s fields fit in the table (there are a lots of fields using variable colspan values, and you have the photo card on the upper right of the table which is also a special case that you will have to adapt).
So, the bottom line is that even if it’s possible, it will be very tricky to do for you, this will cost you a good amount of time, and in the end the table may be broken (remember that Dolibarr has a lot of different scenarios, so even if your table shows correctly for you, you will have to test every possible combination of variables and settings for the module you are working on to ensure that the table doesn’t break when you add an optional feature, let’s say for example the photo card, or a comment note, etc.). Also, your table may break anytime in the future when you update your Dolibarr’s install, you will maybe have to redo all your work, things are changing fast currently in the codebase…
So I advise you to just tell your boss that this is too much complicated given today’s web standards and that this would break Dolibarr’s flexibility and maintenance, and that his time (and yours) is better spent elsewhere
@rompp an additional note about this issue: if Dolibarr used divs to represent the tables, or another more flexible and modern XHTML construct, it would be far easier to extend the display and adapt it to whatever purpose. But currently the app still relies on tables and I don’t know of any plans to convert to another construct (and this would be quite a huge load of work).
New added features in CustomFields Pro:
- AJAX support! Now CustomFields Pro can use AJAX to advise you and autocomplete your entries in the admin panel, and this is also used to manage cascading lists. An AJAX api is provided, so that you can add an AJAX feature to any field (even your customly programmed fields). This is documented on the developper’s wiki in AJAX-PHP callback.
- Cascading lists to make drop-down cascaded list, where the parent list will constraint the options shown in the children lists (yes you can have as many children as you want for one parent).
- Hidden Custom fields, to by default hide a custom field and only show it depending on a parent field’s value (great to create optional fields/forms when combined with cascading lists).
- Separators, a long-standing request, can now be set to visually separate custom fields from other fields above.
- Automatic update notification in admin panel will let you know if a newer version is available, and show you the changelog in case a feature may be of interest to you.
- Lots of minor improvements like automatic scrolling when you add/edit a custom field in the admin panel.
ProductsEasyAccess has also been improved, as it can now generate its own thumbnails without relying on Dolibarr’s system, thus you can now set a custom thumbnail size (which is not permitted by Dolibarr).
New web hosting! This website should now be a lot more fast and available so that you can more comfortably navigate.
And Online demo is back, with Dolibarr v3.7-beta and the very latest CustomFields Pro and ProductsEasyAccess modules, so that you can test the latest features freely from the demo!
I hope this new set of features will please and meet the demands of many users, and provide for an even greater experience with your custom fields.
- Duplicate option to duplicate any (standard or custom) field. This is very useful in combination with the Recursive Remote Fields Access to force generating ODT tags or simply get an easy access in your PDF template to any Dolibarr fields. For example, in your invoices, you can duplicate the Client field, so that you can access any Client’s object field in your templates easily, CustomFields will manage everything for you. More about it here: http://wiki.dolibarr.org/index.php/Module_CustomFields#Duplicate
ANNOUNCEMENT: CustomFields v3 and ProductsEasyAccess are now free and opensource!
You can now download the latest version of CustomFields and ProductsEasyAccess here:
CustomFields and ProductsEasyAccess are now completely opensourced. This was a great adventure, and I want to thank everyone who supported and contributed to the project, which allowed me to continue to develop and add significant new features over the past years.
Nevertheless, it is now time for me to move on to other projects. Thus, I publish these modules under opensource, as was planned from the beginning. I hope that the module will continue to live with the user community, the module being stable enough to continue to work with all future versions of Dolibarr as long as Hooks and Triggers systems do not change.
I therefore will not provide personalized support anymore, but the github is open to all contributors and I will pull for any stable contribution.
I hope this module will continue to provide a tailored user experience to the community of Dolibarr! Enjoy!
I have a fresh installed Dolibarr 3.8.3 on FreeBSD 9.3 with Postgresql and PHP 5.6.16. Also I installed CustomFields 3.5.13. The configuration looks ok, I can access to the setup page of CustomFields, but when I try to start initialize with <Create Table> I got the following messages:
ERROR: 42703: column ‘column_key’ does not exist LINE 3: …A = ‘dolibarr’ AND TABLE_NAME = ‘llx_facture’ AND COLUMN_KEY… ^ LOCATION: errorMissingColumn, parse_relation.c:2655
ERROR: 42703: column ‘column_key’ does not exist LINE 3: …A = ‘dolibarr’ AND TABLE_NAME = ‘llx_facture’ AND COLUMN_KEY… ^ LOCATION: errorMissingColumn, parse_relation.c:2655; ERROR: 42601: syntax error at end of input LINE 1: … llx_facture_customfields( rowid SERIAL PRIMARY KEY ^ LOCATION: scanner_yyerror, scan.l:1045
ERROR: 42703: column ‘column_key’ does not exist LINE 3: …A = ‘dolibarr’ AND TABLE_NAME = ‘llx_facture’ AND COLUMN_KEY… ^ LOCATION: errorMissingColumn, parse_relation.c:2655; ERROR: 42601: syntax error at end of input LINE 1: … llx_facture_customfields( rowid SERIAL PRIMARY KEY ^ LOCATION: scanner_yyerror, scan.l:1045
no, I did not, because I 've read that the author wants only to communicate via the forum and not e-mail.
Ok, I changed the database from postgresql to mysql. Now the modul CustomFields runs like it is expected. Well, other users with postgresql back end watch out, it will not working with this modul.
I cannot get the ODT fields to show replacement value.
The PDF test seems to be working.
In the CustomFields Setup, on the “Customer Invoices” tab, I have a variable name “cf_bankinfo”.
The PDF test from the “Invoice card” screen shows:
bankinfo ($object->customfields->cf_bankinfo): test
bankinfo [raw] ($object->customfields->raw->cf_bankinfo): test
In my customized ODT file I have entered:
{cf_bankinfo}
and all other variables show appropriate values except this one which still shows:
{cf_bankinfo}
instead of the repalcement txt “test”
@Antknee Please make sure your tag was not corrupted with ODT markup (for example when you use backspace to correct your writing, it may insert hidden ODT markup, breaking the tag).
What you can do to ensure that your tag is not broken is to write it down in a simple text editor such as Notepad (or Notepad++ or SublimeText, etc.) and then copy/paste this tag into your ODT document. This should fix your issue.
