Jump to content

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)
Link to comment
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)
Link to comment
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;

 

Link to comment
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)
Link to comment
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...

Link to comment
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)
Link to comment
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 ?

Link to comment
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)
Link to comment
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?

Link to comment
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...

Link to comment
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.

Link to comment
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à ?

Link to comment
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.

Link to comment
Share on other sites

  • 4 months later...
  • 8 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...