Bonjour,
Dolibarr 13.0.1
Après avoir rédigé un devis, je souhaite l’envoyer en y joignant un autre PDF. Opération courante et habituelle.
Cette fois-ci, cela ne fonctionne pas/plus, bien qu’un message vert m’indique : « Fichier(s) téléversés(s) avec succès »
Le fichier téléversé en question n’apparaît pas dans « Fichiers joints », seule le PDF de la propale y figure.
Dans le log de Dolibarr, je ne trouve rien de particulier à part ces WARNINGs récurrents :
WARNING A.B.C.D functions::dol_include_once Tried to load unexisting file: /framework/class/actions_framework.class.php
Concernant le fichier uploadé (prop-tech-NC.pdf), je trouve ces lignes INFO et DEBUG :
DEBUG A.B.C.D dol_add_file_process upload_dir=/home/dolibarr-data/users/3/temp allowoverwrite=1 donotupdatesession=0 savingdocmask=
INFO A.B.C.D functions.lib::dol_mkdir: dir=/home/dolibarr-data/users/3/temp
DEBUG A.B.C.D functions.lib::dol_mkdir: Directory '/home/dolibarr-data/users/3/temp' does not exists or is outside open_basedir PHP setting.
DEBUG A.B.C.D functions.lib::dol_mkdir: Directory '/home/dolibarr-data/users/3/temp' created
DEBUG A.B.C.D Files.lib::dol_move_uploaded_file Success to move /tmp/phpVJ8mL1 to /home/dolibarr-data/users/3/temp/prop-tech-NC.pdf - Umask=0664
puis plus loin :
INFO A.B.C.D dol_delete_file file=/home/dolibarr-data/users/3/temp//prop-tech-NC.pdf disableglob=1 nophperrors=0 nohook=0
DEBUG A.B.C.D Removed file /home/dolibarr-data/users/3/temp//prop-tech-NC.pdf
Et sinon, le répertoire /home/dolibarr-data/users/3 est bien à www-data:www-data ainsi que tout ce qui est dessous.
Où chercher ?
Le problème touche également la partie GED manuelle.
Des répertoires y existent et les compteurs de chacun indique des fichiers contenus, cependant la liste est vide quand on affiche le contenu du répertoire.
Le téléversement d’un fichier produit exactement la même chose : affichage de l’information « Fichier(s) téléversés(s) avec succès » mais pas de fichier téléversé.
En revanche, en téléchargeant deux fois de suite le même fichier dans le même dossier :
« Un fichier portant ce nom existe déjà. »
Le serveur Apache2 n’indique pas d’anomalie dans ses logs (access et error).
Mais là, le log dolibarr crache des ERR :
DEBUG A.B.C.D sql=SELECT t.rowid, t.label, t.fk_parent, t.description, t.cachenbofdoc, t.fk_user_c, t.fk_user_m, t.date_c as date_c, t.tms as date_m FROM llx_ecm_directories as t WHERE t.rowid = 1
ERR A.B.C.D DoliDBMysqli::query SQL Error message: DB_ERROR_NOSUCHFIELD Unknown column 't.tms' in 'field list'
Plus loin :
DEBUG A.B.C.D sql=UPDATE llx_ecm_directories SET cachenbofdoc = cachenbofdoc + 1 WHERE rowid =
ERR A.B.C.D DoliDBMysqli::query SQL Error message: DB_ERROR_SYNTAX You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
Plus loin :
DEBUG A.B.C.D sql=SELECT t.rowid, t.label, t.fk_parent, t.description, t.cachenbofdoc, t.fk_user_c, t.fk_user_m, t.date_c as date_c, t.tms as date_m FROM llx_ecm_directories as t WHERE t.rowid = 1
ERR A.B.C.D DoliDBMysqli::query SQL Error message: DB_ERROR_NOSUCHFIELD Unknown column 't.tms' in 'field list'
Du mieux, du moins pour la partie GED manuelle pour le moment.
La table llx_ecm_directories ressemblait à ça :
+--------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+----------------+
| rowid | int(11) | NO | PRI | NULL | auto_increment |
| label | varchar(64) | NO | MUL | NULL | |
| entity | int(11) | NO | | 1 | |
| fk_parent | int(11) | YES | | NULL | |
| description | varchar(255) | NO | | NULL | |
| cachenbofdoc | int(11) | NO | | 0 | |
| fullpath | varchar(750) | YES | | NULL | |
| extraparams | varchar(255) | YES | | NULL | |
| date_c | datetime | YES | | NULL | |
| date_m | timestamp | YES | | NULL | |
| fk_user_c | int(11) | YES | MUL | NULL | |
| fk_user_m | int(11) | YES | MUL | NULL | |
| acl | text | YES | | NULL | |
+--------------+--------------+------+-----+---------+----------------+
Sur une autre instance 13.0.1, le champ date_m est remplacé par tms, comme suit :
| tms | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
Pour corriger ça, il faut passer ces commandes MYSQL :
-
UPDATE llx_ecm_directories SET date_m = CURRENT_TIMESTAMP where date_m IS NULL;
-
ALTER TABLE llx_ecm_directories CHANGE date_m tms TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP;
Et on retrouve tous ses petits dans la GED manuelle ! 
En revanche, toujours pas d’ajout de fichier dans l’envoi de mail sur une propale… À suivre (ou pas) !
Même motif, même punition, mais là ça se passe dans beaucoup de tables !
J’ai rapidement trouvé llx_propal et llx_user mais là, il m’en reste 156 à corriger ! 
Pourquoi ? Comment une telle anomalie peut se produire ?
Dans 156 tables le champ tms peut être NULL, n’est pas le current timestamp par défaut, et ne prend pas non plus le current timestamp « on update ».
Chaud ! Et, a priori, je ne vois qu’un upgrade de dolibarr pour entraîner ça…
Du pain sur la planche ! 
Les tables sont corrigées, et ce n’est pas mieux.
Toujours impossible de rajouter des pièces jointes aux envois de propales, mais aussi de factures et sans doute d’autres pièces par mails.
Mais je vois que je ne suis pas le seul à constater ça, c’est rassurant.
Enfin pas la régression par rapport à la v12… 
Merci @Philazerty, c’est peu ou prou une des solutions évoquées dans le ticket que je mentionnais et il semble qu’il y ait eu une (vraie) solution trouvée qu’on pourra trouver dans la prochaine version (on l’espère).
Bonsoir
Même problème en V12.05, la solution proposée par Phil a fonctionné
Merci !
