Accepter/refuser propale impossible suite migration séquentielle 3.4.2 vers 12.0.3

Bonjour,
Je teste la migration d’une version 3.4.2 vers la version 12.0.3 (oui, je suis « conservateur »…), en passant séquentiellement par toutes les versions majeures intermédiaires.
Je parviens à créer des propositions commerciales, à la valider, à les envoyer par mail, mais une fois que la proposition est validée, je n’ai plus la possibilité d’accepter ou refuser (signée / non signée) la proposition.
Le bouton « accepter/refuser » n’apparaît pas.
Quelqu’un aurait-il une idée sur l’erreur de manipulation ou le détail de paramétrage qui en serait la cause ?
La version 12.0.3 tourne sur une machine Debian 10.5, avec Apache/2.4.38, PHP 7.3.19-1~deb10u1 et MySQL or MariaDB 5.5.5-10.3.23-MariaDB-0+deb10u1.
Merci d’avance !

Je penche pour un droit manquant :

$usercanclose = ((empty($conf->global->MAIN_USE_ADVANCED_PERMS) && $usercancreate) || (!empty($conf->global->MAIN_USE_ADVANCED_PERMS) && !empty($user->rights->propal->propal_advance->close)));

[…]

// Close as accepted/refused
if ($object->statut == Propal::STATUS_VALIDATED && $usercanclose) {
	print '<a class="butAction" href="'.$_SERVER["PHP_SELF"].'?id='.$object->id.'&amp;action=closeas'.(empty($conf->global->MAIN_JUMP_TAG) ? '' : '#close').'"';
	print '>'.$langs->trans('SetAcceptedRefused').'</a>';
}

Bonjour,
Merci d’avoir pris le temps de répondre.
Je ne parviens cependant pas à comprendre de quel droit il s’agit, ni à quel endroit régler ce problème.
Pourriez-vous m’en dire un peu plus ?
Bien cordialement,

Bonjour,

Tout d’abord, vérifiez dans Accueil > Configuration > Sécurité si l’option « Utiliser les droits avancés dans les permissions des modules » est activée.

Allez ensuite sur votre fiche utilisateur (vous pouvez y accéder par un menu qui se trouve tout à droite du bandeau principal). Rendez-vous dans l’onglet « permissions », puis cherchez la section « Propositions commerciales ».

Là, si vous avez les droits avancés, assurez-vous que vous avez le droit « Clôturer les propositions commerciales » (si vous avez le droit, un s’affiche ; si vous ne l’avez pas, un + s’affiche).

Si vous n’avez pas l’option « droits avancés », c’est le droit « créer / modifier des propositions commerciales » qui définit si vous pouvez passer une proposition à « acceptée » ou « refusée ». Cependant, si vous n’aviez pas ce droit, je ne vois pas comment vous auriez pu créer la proposition.

Si les droits sont déjà OK, ça veut dire que le problème est ailleurs, mais on aura au moins avancé.

Bonsoir,
Merci pour ces détails.
Les droits sont accordés comme cela doit l’être, et surtout comme cela l’était avant la migration. Les utilisateurs concernés ont bien tous les droits de créern modifier, valider, envoyer, clôturer les propositions commerciales.
Je cherchais sutrout à comprendre votre réponse et le code que vous avez cité : s’il s’agit de modifications à effectuer dans le code, je ne sais dans quel fichier le faire.
Bien cordialement

Bonsoir,

Le code posté au dessus et celui de l’affichage du bouton, rien à modifier pour vous.

Elle est active ou pas ?
Dans tous les cas vous pouvez essayer de la désactiver, verifier les droits et verifier si ça marche.
Sinon faire l’inverse.
SI toujours rien, essayez de désactiver le module devis puis réactiver le

Bonjour,

Je vous confirme que l’option « utiliser les droits avancés » est active.

Je l’ai désactivée, puis réactivée, sans effet sur mon problème.

J’ai également désactivé et réactivé le module propositions commerciales, également sans effet. Je n’ai toujours pas la possibilité de voir le bouton « accepter/refuser ».

Merci pour votre disponibilité !

Bonjour,

J’ai tenté plusieurs manipulations comme par exemple désactiver et réactiver un à un tous les modules… mais toujours pas de bouton « accepter/refuser » dans mes propales.

En examinant le log, j’ai trouve 2 warnings concernant un appel à un module (Node de frais +) qui a été désinstallé avant la migration :

2020-12-01 07:41:05 WARNING 192.168.1.153 functions::dol_include_once Tried to load unexisting file: /ndfp/core/boxes/box_ndfp.php
2020-12-01 07:41:05 WARNING 192.168.1.153 Failed to load box ‹ box_ndfp › into file ‹ /ndfp/core/boxes/box_ndfp.php ›

Est-il possible que les « résidus » des modules précédemment installés et désinstallés puissent causer le problème ? Dans ce cas, comment nettoyer convenablement la base de données / les répertoires ?

Bien cordialement

Bonjour,

Oui c’est possible d’avoir des choses qui trainnent.

A votre place je tenterai de supprimer tous les fichiers dolibarr et de copier uniquement ceux d’une V12.
Histoire d’être sur qu’il n’y ai pas un vieux fichier php qui traine quelque part.

Merci ksar,

Je viens de tenter l’opération en connectant une installtion toute fraîche de Dolibar 12.0.3 sur la base de données, mais le resultat est inchangé.

C’est donc dans la base de données que ça se passe…

Dans la table llx_const j’ai bien trouvé des lignes « main_module_ndfp » et j’ai mis la valeur à « 0 » pour chacune d’elles.

Il doit être nécessaire de faire du nettoyage ailleurs, mais je ne sais pas où. Si quelqu’un a une piste à me suggérer, je suis preneur !

Bonjour,
A ce stade, il faut passer au débogage engagé.
Il faudrait faire une sortie de toutes les variables impliquées dans le test d’apparition du bouton.

echo "usercanclose : " . $usercanclose . "\n"; 
echo "MAIN_USE_ADVANCED_PERMS" . (empty($conf->global->MAIN_USE_ADVANCED_PERMS) ? "Rien" :  $conf->global->MAIN_USE_ADVANCED_PERMS) . "\n";
echo "usercancreate : " . $usercancreate . "\n"; 
echo "Permission : " . (!empty($user->rights->propal->propal_advance->close) ? "Renseigné" : "Vide") . "\n";
echo "Statut : " . $object->statut . "\n"; 
echo "STATUS_VALIDATED : " . Propal::STATUS_VALIDATED . "\n";
// Close as accepted/refused

Je n’ai pas vérifié que le code s’exécutait.

Bonjour yves57,

Voici les résultats :

usercanclose :
MAIN_USER_ADVANCED_PERMS : 1
usercancreate :
permission : vide
statut : 1
STATUS_VALIDATED : 1

C’est donc bien un problème de permissions…

Oui, et en particulier :
$user->rights->propal->propal_advance->close n’est pas défini. Donc j’interprète ça en considérant que l’utilisateur n’a pas le droit de cloturer les propositions.

Dans la table llx_rights_def les droits associés au module propale sont les suivants

MariaDB [dolibarr]> select id, module, perms from llx_rights_def where module like "propale";
+----+---------+----------------+
| id | module  | perms          |
+----+---------+----------------+
| 21 | propale | lire           |
| 22 | propale | creer          |
| 24 | propale | propal_advance |
| 25 | propale | propal_advance |
| 26 | propale | cloturer       |
| 27 | propale | supprimer      |
| 28 | propale | export         |
+----+---------+----------------+

Je retouve bien ces droits accordés au fk_user que j’utilise pour mes tests dans la table llx_user rights :

MariaDB [dolibarr]> select * from llx_user_rights where fk_user = 2 and fk_id like "2_" order by fk_id asc;
+-------+--------+---------+-------+
| rowid | entity | fk_user | fk_id |
+-------+--------+---------+-------+
|  2414 |      1 |       2 |    21 |
|   489 |      1 |       2 |    22 |
|   490 |      1 |       2 |    24 |
|   491 |      1 |       2 |    25 |
|  2415 |      1 |       2 |    26 |
|   493 |      1 |       2 |    27 |
|   494 |      1 |       2 |    28 |
+-------+--------+---------+-------+

Je n’ai pas d’id 23 dans llx_rights_def, est-ce normal ?

Je n’ai pas non plus, on dira donc normal.
Tu devrais ajouter la colonne subperms de la table llx_rights_def, puisque tu utilises les droits avancés, ce qui correspond à propal_advance, je présume.

Voilà.

MariaDB [dolibarr]> select id, module, perms, subperms from llx_rights_def where module like "propale";
+----+---------+----------------+----------+
| id | module  | perms          | subperms |
+----+---------+----------------+----------+
| 21 | propale | lire           | NULL     |
| 22 | propale | creer          | NULL     |
| 24 | propale | propal_advance | validate |
| 25 | propale | propal_advance | send     |
| 26 | propale | cloturer       | NULL     |
| 27 | propale | supprimer      | NULL     |
| 28 | propale | export         | NULL     |
+----+---------+----------------+----------+

Je viens de jeter un oeil dans une installation fraîche de la version 12.0.3 qui fonctionne convenablement, les droits sont identiques. Le mystère est toujours là…

Pour le moment je cherche à comprendre comment Dolibarr charge / actualise les droits de l’utilisateurs.

Perso, je dirais qu’il manque une ligne propal_advance, cloturer, ou close

Perso, je dirais qu’il manque une ligne propal_advance, cloturer, ou close

C’est bien probable car lorsque je désactive les droits avancés (configuration/sécurité), le bouton « accepter/refuser » s’affiche et il est possible de passer la propale au statut signé ou non signé.

1 « J'aime »

Il manque en effet une ligne dans la table right_def

+----+---------+----------------+----------+
| id | module  | perms          | subperms |
+----+---------+----------------+----------+
| 29 | propale | propal_advance | close    |
+----+---------+----------------+----------+

Une fois la ligne ajoutée, dans les droits des utilisateurs et groupes une nouvelle ligne s’ajoute et une fois activée les boutons reviennent

Bonjour , est ce que le problème a été résolu, j’ai un probleme , similaire je ne peux accepter ou refuser les propal que nous avons lancé, il y a bien le bouton mais il est bloqué et pourtant j’ai le profil superadmin donc toutes les permissions . J’ai essayé avec un autre priofil configuré aussi admin