Changes

m
Line 944: Line 944:     
== Should do ==
 
== Should do ==
 +
* Add the possibility to make a custom field uneditable (only filled using overloading functions).
 +
* Add the possibility to make a custom field required to create an object (use JSON extraoptions).
 +
* Add the possibility to mark a custom field to be shown in tables listings (eg: as a column in products listings) with "order by this column" buttons and stuffs. Will be difficult if the hooks are not yet implemented in listings.
 +
* Automatically on conversion trigger, copy the custom fields that have the same name (eg: cf_theme exists in both propal and invoice, then when converting propal -> invoice the custom field will be copied automatically). (Automatically copy custom fields if extra option "migrate" is enabled and a target custom field with the same name exists? Needs to catch the right event (validate?) - maybe with a trigger?)
 
* Checkbox (multiple checkboxes, one for each possible value) and multiselect (big select and can use SHIFT to multiselect) (store in XML file) (but impossible with constrained fields, can't store multiple foreign keys ids in one single sql field, but would work for other types like enum)
 
* Checkbox (multiple checkboxes, one for each possible value) and multiselect (big select and can use SHIFT to multiselect) (store in XML file) (but impossible with constrained fields, can't store multiple foreign keys ids in one single sql field, but would work for other types like enum)
 
use fieldset, input checkbox and label for, eg:
 
use fieldset, input checkbox and label for, eg:
Line 953: Line 957:  
* 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').
 
* 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').
 
* Add a javascript options values generator for the enum type (a hidden input that would be shown only when DropdownBox type is selected and that would permit to add options by clicking a plus button).
 
* Add a javascript options values generator for the enum type (a hidden input that would be shown only when DropdownBox type is selected and that would permit to add options by clicking a plus button).
* Replace triggers in customfields class by hookmanager.
+
* Replace triggers in customfields class by hookmanager?
 
* Replace extend class by hookmanager if possible (but how to simulate the *full switch?).
 
* Replace extend class by hookmanager if possible (but how to simulate the *full switch?).
* Add the possibility to make a custom field uneditable (only filled using overloading functions).
  −
* Add the possibility to make a custom field required to create an object (use JSON extraoptions).
  −
* Add the possibility to mark a custom field to be shown in tables listings (eg: as a column in products listings) with "order by this column" buttons and stuffs. Will be difficult if the hooks are not yet implemented in listings.
  −
* Automatically on conversion trigger, copy the custom fields that have the same name (eg: cf_theme exists in both propal and invoice, then when converting propal -> invoice the custom field will be copied automatically).
   
* AJAX previsualisation of the HTML custom field that will be created.
 
* AJAX previsualisation of the HTML custom field that will be created.
 
* 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.
* Automatically copy custom fields if extra option "migrate" is enabled and a target custom field with the same name exists? Needs to catch the right event (validate?) - maybe with a trigger?
   
* 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?).
 
* Implementation of custom fields in CSV exports (may need a few new hooks in Dolibarr?).
439

edits