Ce beug vient d’une limitation du serveur, il y a trop de tâche et jours.
je réfléchis a une solution mais c’est pas simple(soit des pages soit une refonte complète de l’affichage). Il y a une issue d’enregistré sur le GitHub pour ça.
En attendant vous pouvez
Soit modifier php.ini pour supporter plus de 1000 champ
Soit passer par un affichage par semaines
ou désactiver les notes journalière (si elle sont activent)
Soit fermé des tâches si vous le pouvez
En mode semaine il faut 92 tâches pour que ça bloque
Nous avons effectivement beaucoup de tâches en mode semaine. Ce serait plus simple de modifier le php.ini si je comprend bien.
Ou trouver le fichier php.ini et comment fait-on pour le modifier pour supporter plus de 1000 champ ?
Dans le fichier php.ini (son emplacement dépend de votre système) il faut changer max_input_vars
Pour les rapports, j’ai une version 4.0.4 qui devrait marcher mais les exports bug toujours sur mes machines de tests donc je ne pas vérifier. (sans doute du au fait que j’ai 5 instances qui tournent sur le même virtual host)
je viens de tester la version 4.0.4 du module timesheet :
j’ai testé sur une base de test où il y a peu de projets/activités : il faut pas mal de temps (plusieurs seconde) pour obtenir un résultat lorsqu’on clique sur « exporter ».
j’ai comme résultat une page blanche, mais c’est peut être dû à votre remarque «Attention il faut l’extension php xml et zip pour que ça fonctionne.» Où et comment faut-il installer ces extensions ?
Ce me semble vraiment bien d’avoir créé cette fonctionnalité.
Pour l’erreur sur les jours ouvert, c’est corrigé je ferai le zip ce weekend. le support de beaucoup de tâches y sera aussi présent.
Pour Excel je m’arrache les cheveux car je n’ai aucune erreur mais ça marche plus du tout chez moi … par contre les exports csv ou tsv fonctionnent très bien donc je pense que je vais forcer ce format (pour tester, il faut juste remplacer excel2007 par csv dans le lien ouvert avec le bouton exporter)
pailletm, les exports xlsx fonctionnent toujours sur ton install ? si oui peux tu me donner ta version php et si le module est dans un dossier custom ou directement dans htdocs ?
Merci d’avance
note: le code des export excel semble looper dans lors de new PHPExcel, au moment de la création de la worksheet, code qui est hors du module et qui fonctionne très bien pour les exports dolibarr …
je suis sur une install neuve de dolibarr v9.0.0.
v. 4.0.4 de Timesheet et ça fonctionne avec un php 7.2.4 et le répertoire timesheet placé dans htdocs.
le xlsx est bien généré.
si besoin je peux tester sur d’autres version php.
j’ai mis l’export en tsv par defaut mais c’est modifiable avec cette variable TIMESHEET_EXPORT_FORMAT voici les valeurs possible
excel -> xls
excel2007 ->xlsx
tsv -> tsv
csv -> cvs
Aussi si TIMESHEET_EVAL_ADDLINE = 1, l’ajout de ligne « supporte » les taxes additionnelles, les trad … mais c’est encore expérimental (la façon dont est codé dolibarr ne permet pas de faire ça proprement …)
désolé si y a des beug depuis fin fev jusqu’a juin je n’ai qu’un 12 pouce pour coder ce qui n’est pas ideal … de plus je n’ai pas tout mes outils en place pour les verif auto …
après migration de la version 7 vers la version 9.0.1, nous avons des erreurs lorsque nous accédons à l’onglet de la feuille de temps, visiblement liées à une fonction mysql inexistante sur postgresql. (cf capture écran en P.J.).
Infos version:
Dolibarr: 9.0.1
OS: CentOS 7
PHP: 7.2.10
Base de données: postgresql 9.2.24
Httpd: Apache/2.4.6 (CentOS)
Je n’ai pas trouvé de thread relatif à ce problème sur le forum, désolé par avance si c’est un doublon.
Pour l’erreur pgsql je suis étonné car mon serveur est aussi sur pgsql et je l’ai pas, avez-vous la dernière version du module ?
L’erreur en elle-même est simple pgsql ne supporte pas les doubles quotes pour les variables, seul les noms de colonne peuvent les utiliser
Pour le core, c’est une License OpenSource donc ils peuvent tout reprendre (ex: le javascript du core est celui du module 1.4) et je fais en sorte de respecter de plus en plus les normes du core mais je ne le ferai pas moi-même car je n’arrive déjà pas à faire intégrer des changements simples (page de téléchargement de tous les documents générés entre deux dates pour faire les dossiers mensuel/trimestriel pour le comptable) :
Dolibars version 6.0.6 php 7.3.3 module Timesheet 4.0.6
Nous avons un soucis avec l’affichage des rapports. Sur le rapport compatible export l’affichage des heures jours n’est pas très cohérent mais respecte les durées des heures introduites et les dates des jours. Mais dès que vous décochez l’export la date du 25.03$ disparaît…
- Il est possible de bloquer la création des TimeSheet avec les chrono fini
- les notes sont bien sauvegardé (contrairement a la 4.0.7)
- la page admin des chrono affiche la durée en heure:minute
d’abord merci pour ce module très intéressant (comme dit ailleurs, il faudrait l’intégrer au core de dolibarr !).
J’ai un bug ou pb de compréhension peut-être.
Ma conf :
dolibarr 9.0.2
timesheet que j’utilisais en version 2.x (ou 3.x je ne sais plus) que j’ai upgradé en 4.0.9.
Paramètres généraux de timehseet : gestion en heure, validation par semaine, intégration des congés, pas de gestion de la facturation depuis timesheet (je me sers de timesheet pour que mes collaborateurs fassent leur Compte-Rendu d’Activité d’un point de vue général)
Mon pb :
lorsqu’un user va sur une semaine à saisir, il renseigne donc ses heures sur les différentes tâches, puis dans la logique clique sur ENREGISTRER. Une fois la fin de la semaine, après vérification de sa saisie, il doit donc soumettre la feuille. Il clique sur SOUMETTRE mais là
pb1 : message d’alerte dolibarr « Rien a changé » donc la soumission ne se fait pas.
pb2 : Comportement bizarre ensuite, en navigant entre les champs de saisie des heures, j’ai des erreurs qui remontent: « updateTotal ReferenceError: ‹ time_type › is not defined ».
et pb3 : pas lié aux 2 ci-dessus, mais je n’ai plus les totaux d’heures qui s’affichent en fin de tableau (la ligne TOTAL n’affiche rien sous chaque colonne de jour) or le paramètre afficher le total est bien coché.
pour les 2 premiers pb, astuce : je dis à mes collaborateurs de faire un changement de valeur dans un des champs pour ensuite faire SOUMETTRE tout de suite plutôt que ENREGISTRER et SOUMETTRE. De cette façon la soumission fonctionne.
Des idées pour cela ? J’hésite en attendant à revenir sur une version 3 ou 2, mais j’ai un doute sur la retrocompatibilité dans ce sens (notamment au niveau de la BDD)
…y’a tellement de boulot 
