Jump to content
Ric34

Problème permissions employés STOCK

Recommended Posts

Bonjour à tous,

Je suis sur PS 1.7.5.2 et j'ai un soucis avec l'attribution des permissions des profils employés . Elles fonctionnent pour toutes les lignes sauf STOCK. J'ai bien le message enregistré qui apparaît quand je coche les cases désirées CRUD mais quand j'actualise la page mes modifications appliquées précédemment à la ligne STOCK n'ont pas été prises en compte (cases non cochées) et le profil modifié n'a donc pas accès a ces derniers (modification du stock)...

Ça fonctionne en revanche pour toutes les autres ligne... C'est bizarre.

Personne n'a jamais eu ce soucis ? En BDD ces données ont pourtant été créés avec l'ajout des 4 autorisations associées à la ligne stock.

Merci par avance,

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

Info complémentaire : dans le BO en mode DEV j'ai ce warning quand je vais dans la gestion des autorisations : 

Notice à la ligne 199 du fichier \\controllers\\admin\\AdminAccessController.php
[8] Undefined index: name

 

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

2020-01-24_11h46_30.thumb.png.2a53cbbf87db38dd6e648496a99f24c9.png

 

Je fais des tests en cochant directement sur le filtre tout sélectionner. Mais lorsque j'actualise la page impossible de faire un enregistrement sur la ligne STOCK.

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

En BDD j'ai identifié la table ps_access. Et les valeurs des autorisations STOCK avec 377, 378, 379, 380.

Lorsque j'essaie cette requête SQL afin d'ajouter à mon profil (ID = 7) :

INSERT INTO `ps_access` (`id_profile`, `id_authorization_role`) VALUES ('7', '377'),('7', '378'), ('7', '379'), ('7', '380');

J'ai cette allerte SQL #1062 - Duplicata du champ '7-378' pour la clef 'PRIMARY'

Les nouvelles lignes en BDD ont bien été ajoutées, cependant toujours pas d'accès aux stocks et a leur modification pour le profil en question... Et ces données (ligne stock) ne sont pas cochées dans /employés/autorisations

Auriez-vous une idée ?

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

Déjà afin de faire l'ajustement en bdd:

INSERT IGNORE INTO `ps_access` (`id_profile`, `id_authorization_role`) VALUES ('7', '377'),('7', '378'), ('7', '379'), ('7', '380');

Secondo patcher le controller:

    protected function sortModuleByName($a, $b)
    {
        $moduleAName = isset($a['name']) ? $a['name'] : null;
        $moduleBName = isset($b['name']) ? $b['name'] : null;

        return strnatcmp($moduleAName, $moduleBName);
    }

Tercio, montrer le résultat de cette requête:

SELECT `slug`,
                                    `slug` LIKE "%CREATE" as "add",
                                    `slug` LIKE "%READ" as "view",
                                    `slug` LIKE "%UPDATE" as "edit",
                                    `slug` LIKE "%DELETE" as "delete"
				FROM `ps_authorization_role` a
				LEFT JOIN `ps_access` j ON j.id_authorization_role = a.id_authorization_role
				WHERE j.`id_profile` = 7;

 

Share this post


Link to post
Share on other sites

@doekia Merci de te pencher sur mon problème. Alors

1 - Dans le doute j'ai ajouté  toutes les authorizations contenant "STOCK" soit j'ai effectué cette requête :
 

INSERT IGNORE INTO `ps_access` (`id_profile`, `id_authorization_role`) VALUES ('8', '269'),('8', '270'),('8', '271'),('8', '272'),('8', '365'),('8', '366'),('8', '367'),('8', '368'),('8', '369'),('8', '370'),('8', '371'),('8', '372'),('8', '373'),('8', '374'),('8', '375'),('8', '376'),('8', '377'),('8', '378'), ('8', '379'), ('8', '380'), ('8', '381'), ('8', '382'), ('8', '383'), ('8', '384'), ('8', '385'), ('8', '386'), ('8', '387'),('8', '388'),('8', '653'),('8', '654'),('8', '655'),('8', '656');

2 - Le patch a corrigé mon warning

3 - Voici le résultat de la requête :

2020-01-25_10h46_55.thumb.png.8fcbc3bc0516af22e2d4b5e63586d70a.png

Les permissions STOCK ne sont pas effectives sur ce profil (tests sur ID maintenant 8)

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

NB : je pense que c'est vraiment un problème avec ma BDD. J'ai fait des tests en remplaçant les dossiers classes, modules, controllers, override, js etc. d'un presta 1.7.5.2 d'origine et le problème persiste... Alors que sur cette version d'origine (BDD vierge et d'origine) il n'y a pas ce bug...

Share this post


Link to post
Share on other sites

C'est ajout des droits qui ne marche pas?

Active la console du navigateur, regarde l'appel ajax, quels sont ces paramètres? Quel est la réponse ?

Quand tu injectes directement en BDD le permissions du prodil sont bonne?

Edited by doekia (see edit history)

Share this post


Link to post
Share on other sites

C'est ça, en BO c'est l'ajout de droit pour un profil employé mais que pour la ligne STOCK qui ne fonctionne pas. (tous les autres fonctionnent)

Lorsque j'injecte directement ces droits (pour STOCK) en BDD, le profil en question n'a toujours pas accès à la modification de ces derniers. Et en BO dans AUTORISATIONS (PERMISSIONS ) la ligne STOCK reste inchangé.

Pour les appels ajax je n'arrive pas à les analyser :(

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

En BDD j'ai injecté toutes les authorisations (1 - 1036) sur un nouveau profil vierge de droit.

En BO il ne peut toujours pas modifier les STOCK et voici un aperçu de la page employés/permissions :permissions-stock.thumb.jpg.30cfbd500d1a17b3f8143d1df3de2456.jpg

Share this post


Link to post
Share on other sites

Il  ne doit y avoir qu'un seul appel ajax au moment où tu cliques une permission

https://lab17.enter-solutions.net/******/index.php?controller=AdminAccess&token=c47f1aae92f58b0a1bd4262c7f389ead&ajaxMode=1&id_tab=23&id_profile=2&perm=all&enabled=1&submitAddAccess=1&action=updateAccess&ajax=1&token=c47f1aae92f58b0a1bd4262c7f389ead&_=1580128437855

En developpé ça donne:

controller	AdminAccess
token	[…]
0	c47f1aae92f58b0a1bd4262c7f389ead
1	c47f1aae92f58b0a1bd4262c7f389ead
ajaxMode	1
id_tab	23
id_profile	2
perm	all
enabled	1
submitAddAccess	1
action	updateAccess
ajax	1
_	1580128437855

Sur ma version de base ça fonctionne, même si je trouve cela suspect d'avoir 2x le même token, ce qui devrait causer le code à être invalide.

Ici j'ai changé le profil d'origine Logisticien. Peux-tu contrôler avec un profil natif ?

Share this post


Link to post
Share on other sites
1 hour ago, doekia said:

Il  ne doit y avoir qu'un seul appel ajax au moment où tu cliques une permission

Effectivement, j'ai donc effectué le test sur un profil de base "admin" (id ->2) avec toutes les permissions "all" pour la ligne STOCK.

L'appel :

http://tcd.local/adminxxxxxxxx/index.php?controller=AdminAccess&token=b45900588ea92ec81c927b0cd375b393&ajaxMode=1&id_tab=9&id_profile=11&perm=all&enabled=1&submitAddAccess=1&action=updateAccess&ajax=1&token=b45900588ea92ec81c927b0cd375b393&_=1580132569564

Le développé avec aussi ces 2 tokens :

controller: AdminAccess
token: b45900588ea92ec81c927b0cd375b393
ajaxMode: 1
id_tab: 9
id_profile: 11
perm: all
enabled: 1
submitAddAccess: 1
action: updateAccess
ajax: 1
token: b45900588ea92ec81c927b0cd375b393
_: 1580132569564

NB En actualisant la page toujours les même problème sur ce profil de base, sur ligne stock toutes les permissions ne sont pas cochées, et ce profil ne peux pas modifier le stock... 

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

Info complémentaire : ce qui est étrange c'est qu'en BDD ces enregistrements ont bien été créés pour la ligne STOCK avec l'ajout des 4 nouvelles valeurs correspondant aux permissions STOCK

Edited by Ric34 (see edit history)

Share this post


Link to post
Share on other sites

admin n'est pas un profil natif

Les seuls sont: Logisticien, Traducteur et Commercial

Share this post


Link to post
Share on other sites
il y a 23 minutes, Ric34 a dit :

Info complémentaire : ce qui est étrange c'est qu'en BDD ces enregistrements ont bien été créés pour la ligne STOCK avec l'ajout des 4 nouvelles valeurs correspondant aux permissions STOCK

c'est donc que quelque chose efface ensuite... quand tu dis raffraichir, tu reclique sur les choix du menu ou F5?

Share this post


Link to post
Share on other sites

Je viens de me rendre compte qu'en cochant stock ça m'avait coché d'autres lignes également et donc les infos ajax envoyées plus haut ne sont pas les bonnes.

Voici celle correspondant à STOCK

/index.php?controller=AdminAccess&token=b45900588ea92ec81c927b0cd375b393&ajaxMode=1&id_tab=121&id_profile=2&perm=all&enabled=1&submitAddAccess=1&action=updateAccess&ajax=1&token=b45900588ea92ec81c927b0cd375b393&_=1580132569606

controller: AdminAccess
token: b45900588ea92ec81c927b0cd375b393
ajaxMode: 1
id_tab: 121
id_profile: 2
perm: all
enabled: 1
submitAddAccess: 1
action: updateAccess
ajax: 1
token: b45900588ea92ec81c927b0cd375b393
_: 1580132569606

J'ai un id_tab: 121 je ne sais pas si ça pourrait venir de là ? J'ai vu que tu avais de ton côté 23 pour ce dernier. J'ai fait les tests sur un presta vierge même version (1.7.5.2) et il a aussi 23 comme toi pour id_tab quand on modifie les permissions STOCK.

6 minutes ago, doekia said:

c'est donc que quelque chose efface ensuite... quand tu dis raffraichir, tu reclique sur les choix du menu ou F5?

Non ces enregistrements ne s'efface pas de la BDD. C'est juste dans le BO que les cases correspondants à ces enregistrements ne sont pas cochées. Et le profil en question n'a pas la possibilité de modifier le stock...

Share this post


Link to post
Share on other sites

Je veux dire au moment du refresh ça efface car surement un autre tab collise avec le vrai ... du coup les lignes à l'écran se vident et surement la même collision arrive lors de la mise à jour stock

 

Share this post


Link to post
Share on other sites
6 minutes ago, doekia said:

Je veux dire au moment du refresh ça efface car surement un autre tab collise avec le vrai ... du coup les lignes à l'écran se vident et surement la même collision arrive lors de la mise à jour stock

 

Ah ok, j'ai testé des 2 manières, F5 ou directement via le menu.

 

22 minutes ago, doekia said:

admin n'est pas un profil natif

Les seuls sont: Logisticien, Traducteur et Commercial

Effectivement pour mon "admin", c'est "logisticien" que j'avais renommé. Des profils de base vierge de modification je n'en ai plus.

Share this post


Link to post
Share on other sites

Du coup cette id_tab: 121 pour ma ligne stock m'intrigue.

Sachant que tu as 23 et un presta même version aussi 23. (Mes autres lignes ont les même id_tab que celui d'origine, il n'y a que cette ligne STOCK avec mes 121 qui diffère.)

Tu penses que ça pourrait venir de là ?

Share this post


Link to post
Share on other sites

c'est donc un autre controlleur que le Stock de base ... stock avancés?

Share this post


Link to post
Share on other sites
23 minutes ago, doekia said:

c'est donc un autre controlleur que le Stock de base ... stock avancés?

Non c'est bien la gestion de stock de base de Prestashop qui inclus sur les dernières versions la gestion du stock avancé qui n'est plus une option apparemment depuis la 1.7.2.

NB Mais c'est peut être lié car c'etait un prestashop 1.7.1(où le stock avancé était une option) à la base que j'ai déjà mis à jour plusieurs fois pour aujourd'hui être en 1.7.5.2.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More