Bonjour à tous,
Je voudrais notifier une régression concernant des paiements de charges sociales. Je suis passé de la V15.0.3 à 18.0.5.
J’obtiens le message d’erreur :
« Accès refusé.
Vous essayez d’accéder à une page, région ou fonctionnalité d’un module désactivé, ou sans être dans une session authentifiée, ou avec un utilisateur non autorisé. »
Etant donné que cette régression est présente également dans la version de démo en ligne 19.0.0, je vous indique comment le reproduire à cet endroit :
Facturation|Paiement / Charges fiscales/sociales / Règlements.
Dans la liste, le problème apparait sur les réf. Paiement 9 et 10, alors qu’il n’apparait pas sur les réfs 4 6 et 7.
L’url des paiements : Login @ 19.0.0
Ce n’est pas un problème de droit d’accès de l’utilisateur car j’ai le même phénomène avec mon utilisateur SuperAdmin sur qui tous les doits sont activés.
Ce n’est pas une interaction avec un module externe car c’est toujours présent avec tous les modules externes désactivés.
Il n’y avait pas ce problème en V15.0.3
J’ai régénéré le jeton de session en me déconnectant puis reconnectant.
Problème identique avec les versions plus anciennes de php qui sont installées sur le serveur 7.4.33 et 8.0.30
Info d’environnement :
Hébergement sur nos serveurs
OS : Linux Debian
PHP : 8.1.27
Database : MariaDB 10.3.39-MariaDB-0+deb10u2
Si quelqu’un connait le moyen de résoudre ce problème, je suis preneur.
Bonjour,
merci pour ce descriptif précis … est-ce que vous pouvez activer le module debug, passer en debug maximal, provoquer le bug et (m’)envoyer le fichier log ?
alors que sur une autre instance de Dolibarr dans la même version, j’ai bien les lignes pour configurer les logs.
Je précise, car cela peut avoir son importance, que mon instance de Dolibarr a ‹ subi › de nombreuses migrations depuis la version 3.1, alors que l’autre instance a été installée directement en v18.
Je vois également que mon fichier de log a arrêté de se remplir le 20 mars, à priori au moment où j’ai migré en v18.
Est ce qu’il y a moyen d’activer tout cela par les variables ?
si page blanche il faut regarder dans les logs apache. Si c’est concomittant avec la montée en version peut être un problème de droits sur les fichiers ?
@Delthair64
Ce n’est pas une page blanche avec une erreur 500 d’apache. Le corps de la page s’affiche mais il n’y a pas les lignes qui permettent de modifier les constantes pour le syslog. Voir la copie d’écran de mon dernier post. C’est une page incomplète.
@Tonio
J’avais déjà fait ce test. Je viens de désactiver TOUS les modules externes par acquis de conscience. Cela ne résout pas le pb d’affichage de la page de configuration du syslog, ni le pb d’affichage des paiements de charge. Si ce dernier problème était un problème uniquement lié à mon installation, on ne devrait pas le reproduire sur le site demo.
@Erics
En allant directement modifier en base les constantes liés au syslog avec les valeurs qui fonctionnent de l’autre instance, j’ai réussi à ce que les logs s’enregistrent de nouveau au niveau 7 debug. Mais cela ne résout pas la page de config du syslog, mais ce n’est pas le problème du moment.
Je viens de générer 2 fichiers logs et faisant les mêmes manips. Un qui affiche l’erreur avec le paiement 343 et un autre où il n’y a pas l’erreur avec le paiement 327. dolibarr-with-error.log (33,0 Ko) dolibarr-no-error.log (35,6 Ko)
Effectivement, il y avait bien des erreurs 500 dans le log d’apache. Mea culpa sur ce point et après investigation il s’agit de code additionnel chargé de mettre en forme le syslog chromephp et firephp qui doivent dater de lorsque j’étais en v3.1. Une fois les fichiers associés à ces extensions sortis de mon Dolibarr, la page d’admin du syslog s’affiche correctement.
Reste maintenant le fond du pb : l’affichage des paiements de charge.
bonjour,
pour ma part je suis super charrette sur « ma » compta et je débusque des bugs au fil de l’eau … donc pas trop le temps de regarder ce pb en particulier pour les heures à venir
Merci Eric d’avoir pris un peu de temps. Bonne compta… Je compatis.
Si un autre dev se sent de revêtir la tenue de scaphandrier pour plonger dans le code.
Pour rappel la base du site de démo possède des enregistrements qui présentent exactement le même problème, certes en v19. Mais si c’est corrigé en v19, ce sera déjà bien.
