Module CustomFields Dev - Revision history

Eldy at 18:00, 26 July 2019

2019-07-26T18:00:42Z

← Older revision		Revision as of 18:00, 26 July 2019
Line 7:		Line 7:
	devdoc=This page\|		devdoc=This page\|
	userdoc=[[Module_CustomFields]]\|}}		userdoc=[[Module_CustomFields]]\|}}
	~~[[Category:FAQ EN]]~~

	These notes are aimed to developpers who want to extend the functionnalities of the module or want to use it for extreme cases.		These notes are aimed to developpers who want to extend the functionnalities of the module or want to use it for extreme cases.

Lrq3000: /* General purpose SQL methods */

2016-05-10T21:55:28Z

General purpose SQL methods

← Older revision		Revision as of 21:55, 10 May 2016
Line 220:		Line 220:
	* fetchAllTables() fetch a list of all the tables in the database		* fetchAllTables() fetch a list of all the tables in the database
	* fetchPrimaryField($table) fetch the column_name (and only the column_name!) of the primary field of a table. You can then use fetchFieldStruct() with the column_name to get any information you want.		* fetchPrimaryField($table) fetch the column_name (and only the column_name!) of the primary field of a table. You can then use fetchFieldStruct() with the column_name to get any information you want.
	* fetchAny($columns, $table, $where='', $orderby='', $limitby='') allows you to issue any simple SQL query command, for example fetchAny('', 'sometable') is equivalent to SELECT FROM sometable; (but then everything is managed automatically and result is returned to you)		* fetchAny($columns, $table, $where='', $orderby='', $limitby='') allows you to issue any simple SQL query command, for example fetchAny('', 'sometable') is equivalent to SELECT FROM sometable; (but then everything is managed automatically and result is returned to you). NOTE: this method does NOT cache the database results, so that you always get the latest database state (whereas executeSQL() does cache queries to get faster responses).
	* executeSQL($sql, $eventname) to execute any SQL query you want, this will return you a resource (and NOT a processed nuplet like fetchAny!). $eventname can be anything, it's just for Dolibarr logging facility.		* executeSQL($sql, $eventname) to execute any SQL query you want, this will return you a resource (and NOT a processed nuplet like fetchAny!). $eventname can be anything, it's just for Dolibarr logging facility.
	* executeMultiSQL($sql, $eventname) to execute multiple SQL queries		* executeMultiSQL($sql, $eventname) to execute multiple SQL queries

Lrq3000: /* Lines hooks */ Fixed the explanation

2015-10-06T22:27:09Z

Lines hooks: Fixed the explanation

← Older revision		Revision as of 22:27, 6 October 2015
Line 895:		Line 895:

	<source lang="php">		<source lang="php">
	$parameters=array('line'=>$line~~,'fk_parent_line'=>$line->fk_parent_line~~);		$parameters=array('line'=>$line);

	echo $hookmanager->executeHooks('formEditProductOptions',$parameters,$~~this~~,$action);		echo $hookmanager->executeHooks('formEditProductOptions',$parameters,$object,$action);
	</source>		</source>

	~~Hooks~~ names:		The two important things here are that you supply:
	* formEditProductOptions		* $line: the line object, with a $line->rowid property.
	* formCreateProductOptions ($line is not required here, because we create a new product line! you can leave $parameters=array(); empty).		* $object: the parent object of the line, with a $object->rowid property. For example, if $line is an invoice line, then $object must be the parent invoice object. This is necessary so that CustomFields can automatically recognize the link between the twos.

			Possible hooks names:
			* formEditProductOptions: called when you edit a line.
			* formCreateProductOptions: called when you create a line. $line is not required here, because we create a new product line! you can leave $parameters=array(); empty.
	Note: there's no hook for viewing, because showing the customfields will clutter the visual field, but if you really want you can also do it by adding a formViewProductOptions hook.		Note: there's no hook for viewing, because showing the customfields will clutter the visual field, but if you really want you can also do it by adding a formViewProductOptions hook.

Lrq3000: /* Never/Maybe one day */

2015-02-24T14:15:49Z

Never/Maybe one day

← Older revision		Revision as of 14:15, 24 February 2015
Line 1,054:		Line 1,054:
	== Never/Maybe one day ==		== Never/Maybe one day ==
	* Add support for repeatable (predefined) invoices (the way it is currently managed makes it very difficult to manage this without making a big exception, adding specific functions in customfields modules that would not at all will be reusable anywhere else, when customfields has been designed to be as generic as possible to support any module and any version of dolibarr, because it's managed by a totally different table while it's still managed by the same module, CustomFields work with the paradigm: one module, one table).		* Add support for repeatable (predefined) invoices (the way it is currently managed makes it very difficult to manage this without making a big exception, adding specific functions in customfields modules that would not at all will be reusable anywhere else, when customfields has been designed to be as generic as possible to support any module and any version of dolibarr, because it's managed by a totally different table while it's still managed by the same module, CustomFields work with the paradigm: one module, one table).
	* Add an AJAX select box for constrained values : when a constrained type is selected and a table is selected, a hidden select box would show up with the list of the fields of this table to choose the values that will be printed as the values for this customfield (eg: for table llx_users you could select the "nom" field and then it would automatically prepend "nom_" to the field's name).		* Add an AJAX select box for constrained values to automatically select the appropriate name for Smart Value Substitution : when a constrained type is selected and a table is selected, a hidden select box would show up with the list of the fields of this table to choose the values that will be printed as the values for this customfield (eg: for table llx_users you could select the "nom" field and then it would automatically prepend "nom_" to the field's name).
	* Fine-grained rights management: rights per group, per user, and per field.		* Fine-grained rights management: rights per group, per user, and per field.
	* Replace overloading functions (extend class) by hookmanager if possible (but how to simulate the *full switch? Plus this will force users to make their own modules to make those functions, and to disable/renable their modules everytime they will add a new function...).		* Replace overloading functions (extend class) by hookmanager if possible (but how to simulate the *full switch? Plus this will force users to make their own modules to make those functions, and to disable/renable their modules everytime they will add a new function...).
	* Refactor the trigger array: merge it with the modulesarray (along with a new way to specify which customfields trigger action a trigger should correspond, eg: 'linebill_insert'=>'customfields_create'). But the triggers aren't necessarily associated with a specific module...		* Refactor the trigger array: merge it with the modulesarray (along with a new way to specify which customfields trigger action a trigger should correspond, eg: 'linebill_insert'=>'customfields_create'). But the triggers aren't necessarily associated with a specific module...
	* AJAX autocompletion / auto population of field's content when typing the beginning of a value in a text box.		* AJAX autocompletion / auto population of field's content when typing the beginning of a value in a text box.

Lrq3000: /* Never/Maybe one day */

2015-02-24T14:15:15Z

Never/Maybe one day

← Older revision		Revision as of 14:15, 24 February 2015
Line 1,058:		Line 1,058:
	* Replace overloading functions (extend class) by hookmanager if possible (but how to simulate the *full switch? Plus this will force users to make their own modules to make those functions, and to disable/renable their modules everytime they will add a new function...).		* Replace overloading functions (extend class) by hookmanager if possible (but how to simulate the *full switch? Plus this will force users to make their own modules to make those functions, and to disable/renable their modules everytime they will add a new function...).
	* Refactor the trigger array: merge it with the modulesarray (along with a new way to specify which customfields trigger action a trigger should correspond, eg: 'linebill_insert'=>'customfields_create'). But the triggers aren't necessarily associated with a specific module...		* Refactor the trigger array: merge it with the modulesarray (along with a new way to specify which customfields trigger action a trigger should correspond, eg: 'linebill_insert'=>'customfields_create'). But the triggers aren't necessarily associated with a specific module...
	* ~~Compatibility with~~ the ~~native Import module~~.		* AJAX autocompletion / auto population of field's content when typing the beginning of a value in a text box.

Lrq3000: /* Never/Maybe one day */

2015-02-11T18:20:04Z

Never/Maybe one day

← Older revision		Revision as of 18:20, 11 February 2015
Line 1,058:		Line 1,058:
	* Replace overloading functions (extend class) by hookmanager if possible (but how to simulate the *full switch? Plus this will force users to make their own modules to make those functions, and to disable/renable their modules everytime they will add a new function...).		* Replace overloading functions (extend class) by hookmanager if possible (but how to simulate the *full switch? Plus this will force users to make their own modules to make those functions, and to disable/renable their modules everytime they will add a new function...).
	* Refactor the trigger array: merge it with the modulesarray (along with a new way to specify which customfields trigger action a trigger should correspond, eg: 'linebill_insert'=>'customfields_create'). But the triggers aren't necessarily associated with a specific module...		* Refactor the trigger array: merge it with the modulesarray (along with a new way to specify which customfields trigger action a trigger should correspond, eg: 'linebill_insert'=>'customfields_create'). But the triggers aren't necessarily associated with a specific module...
			* Compatibility with the native Import module.

Lrq3000: /* To Do */

2015-02-11T18:19:29Z

To Do

← Older revision		Revision as of 18:19, 11 February 2015
Line 1,025:		Line 1,025:

	== To Do ==		== To Do ==
	~~Nothing here~~!
			* Better management of hidden fields with custom cascading (eg: works great on creation form, but on edit form and creation form with edit action, if the parents already have a value, the hidden fields will stay hidden! This is because of the AJAX is not called, and this is normal). -> Propose a better custom cascade function storing the hidden field's state inside extraoptions?

	== To Document ==		== To Document ==

Lrq3000: /* Should do */

2015-02-11T18:17:15Z

Should do

← Older revision		Revision as of 18:17, 11 February 2015
Line 1,045:		Line 1,045:
	* In ODTs, create special tags to directly access day, month or year value of a date type field independently of the rest.		* In ODTs, create special tags to directly access day, month or year value of a date type field independently of the rest.
	* New overloading function's action: "get", similar to view except that it works not only on Dolibarr's view but whenever someone tries to access this field's value.		* New overloading function's action: "get", similar to view except that it works not only on Dolibarr's view but whenever someone tries to access this field's value.
	* Implementation of custom fields in CSV exports (may need a few new hooks in Dolibarr?).
	* Add Upload and Image field types (this would allow for an easier integration inside ODT and PDF templates than the current workflow of Dolibarr).		* Add Upload and Image field types (this would allow for an easier integration inside ODT and PDF templates than the current workflow of Dolibarr).

Lrq3000: /* Printing in documents */

2015-02-03T22:39:51Z

Printing in documents

← Older revision		Revision as of 22:39, 3 February 2015
Line 505:		Line 505:
	Another method '''printFieldPDF()''' can be used to properly print a value for a PDF (properly encoding the characters).		Another method '''printFieldPDF()''' can be used to properly print a value for a PDF (properly encoding the characters).

	Powertip: this function can also be used to get the Smart Value ~~Substitued~~ value of the field (instead of printing the rowid) in the field is constrained.		Powertip: this function can also be used to get the Smart Value Substituted value of the field (instead of printing the rowid) in the field is constrained.

	=== Simple printing in documents ===		=== Simple printing in documents ===

Lrq3000: /* Simple printing in documents */

2015-02-03T22:39:36Z

Simple printing in documents

← Older revision		Revision as of 22:39, 3 February 2015
Line 523:		Line 523:

	Another method '''simpleprintFieldPDF()''' can be used to properly print a value for a PDF (properly encoding the characters).		Another method '''simpleprintFieldPDF()''' can be used to properly print a value for a PDF (properly encoding the characters).

			Powertip: this function can also be used to get the Smart Value Substituted value of the field (instead of printing the rowid) in the field is constrained.

	=== Find the label ===		=== Find the label ===