439
edits
Module CustomFields Dev: Difference between revisions
Jump to navigation
Jump to search
→TO DO: Added a few more known bugs
mNo edit summary |
(→TO DO: Added a few more known bugs) |
||
| Line 308: | Line 308: | ||
= TO DO = | = TO DO = | ||
To Do | |||
== To Do == | |||
* Add a confirmation when deleting a custom field (because user's datas are lost forever!). | * Add a confirmation when deleting a custom field (because user's datas are lost forever!). | ||
Should do | |||
== Should do == | |||
* 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 322: | Line 324: | ||
* 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). | ||
Known bugs | |||
== Known bugs == | |||
* in product and service modules, if you edit a field, the proposals and other fields below won't be shown, you need to refresh the page. This problem resides in Dolibarr I think (since we are simply using a hook). | * in product and service modules, if you edit a field, the proposals and other fields below won't be shown, you need to refresh the page. This problem resides in Dolibarr I think (since we are simply using a hook). | ||
* ficheinter (Intervention module) custom fields will stay in create mode just after create page is submitted (this is because of the $action that is not standard - $action=edit or something). | |||
* after the edition or creation of a custom field for product lines, the fields in the creation zone are still prefilled with the last entered values of the custom fields (they should be empty, but the problem is that CustomFields automatically reload the last values entered in case there is an error, and the problem lies in the fact that after the creation/edition of a product line, there is absolutely no way to know if the page was reloaded due to an error or if everything is OK). Usually with other modules and mechanisms of Dolibarr, after creation/edition, the page is reloaded and $action is changed, but here it doesn't. | |||
Maybe solution: look at the $object->$error or $object->$errors? but this is not a safe way, the variable name may change, or the error may be emptied... | |||
Never/Maybe one day | == Never/Maybe one day == | ||
* Add Upload field type (almost useless since we can attach files). | * Add Upload field type (almost useless since we can attach files). | ||
* 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). | ||