|
|
[LVM] Retour d'expérience n°5 : user externe (0 lecteur(s))
 | | |
|
SUJET: [LVM] Retour d'expérience n°5 : user externe
|
|
|
|
[LVM] Retour d'expérience n°5 : user externe
|
|
Bonsoir,
ce post 'évolutif' est centré sur mes tribulations Dolibarresques depuis 4/5 mois.
J'ai ainsi du 'faire face' à un choix interne qui a réduit 'arbitrairement' les droits des users 'externes' (=un user Dolibarr dont la société 'nommée' n'est pas celle 'implicite' de tous les users 'internes' et qui 'contrôle' le site web Dolibarr) directement dans le code php et non dans les tables usuelles définissant les permissions et les accès des users (internes ou externes). C'est un choix qui peut sembler 'naturel' au premier abord mais il est restrictif et surtout il 'déporte' la gestion des droits dans le code alors que la gestion des droits est par ailleurs 'centralisée' dans des tables de droits (pas aussi fin que l'on voudrait mais la démarche est bonne). Cela doit être dû à l'historique sans doute (pas de user externe au départ) mais c'est très limitatif car l'intérêt d'un user externe est qu'il est relié à une société. et si il est relié à une société on peut créer des factures. Cela devient primordial si on a des revendeurs (que l'on facture) et des apporteurs d'affaire (qui nous facture mais à qui on envoie des 'appels à facturation') à qui on donne accès au système d'information Dolibarr pour les aider à gérer leurs prospects et à créer des propositions standardisées de qualité. J'ai donc du débloquer le code (et il reste quelques zones que je n'ai pas touché comme les 'box' d'information de l'accueil). Un user externe et un user interne doivent donc être à 'égalité', seules les permissions accordées dans l'interface d'administration doivent faire la différence.
La seconde chose qui découle de l'ouverture à l'extérieur pour la catégorie 'revendeur' des utilisateurs externes est le besoin de 'basculer' le couple acheteur/vendeur entre la proposition et la facture. En effet un revendeur crée une proposition à destination d'un 'client final' mais ensuite il doit être lui même facturé par nous. Il faut donc 'inverser' les rôles. Après mûre réflexion, la modification la plus indolore a été de créer cette inversion à la signature de la proposition où une commande est 'naturellement' créée. La commande, dans le cas Revendeur (=catégorie), est donc la base à partir de laquelle une facture peut être créée (dans tous les autres cas on n'utilise pas la 'filière commande' car on crée une facture directement à partir de la proposition). Et cette commande est liée à une proposition 'source' ce qui fait que l'on a l'information du client final (elle n'est pas perdue), tout ceci sans avoir besoin de re-saisir une commande. Les prix sont aussi modifiés en se basant sur le niveau de prix attribué au revendeur.
A un prochain post...
Romain
|
|
|
|
|
|
|
|
Re:[LVM] Retour d'expérience n°5 : user externe
|
|
là il faudra comparer avec l'existant, car je ne vois pas trop ce que tu as pu apporter de plus
|
|
|
|
Régis Houssin
Contributeur Dolibarr
----------------------------------------
Offre SaaS de Dolibarr
Plateforme de développement Dolibarr
----------------------------------------
Merci de nous aider en effectuant un don via le lien de la page d'accueil.
Et à défaut merci à tout ceux qui cliquent sur les pubs.
|
|
|
|
Re:[LVM] Retour d'expérience n°5 : user externe
|
|
Le statut de user 'externe' (= 'compte Dolibarr') ne permet pas actuellement dans Dolibarr d'autoriser un utilisateur externe d'avoir les mêmes droits potentiellement qu'un user 'interne'. Il y a des restrictions d'office dans le code (if ($socid) ...) quelles que soient les droits par ailleurs définis pour ce user. Il y a donc 'conflit' entre les droits initialisés au niveau de la plate-forme d'administration (configuration) et des 'freins' inclus, eux, directement dans le code. Ainsi dans la version actuelle de Dolibarr le user 'externe' peut voir uniquement sa société alors que dans mon besoin j'ai besoin de justement l'inverse (cela rejoint la stratégie des utilisateurs qui ne doivent pas pouvoir modifier leurs propres informations. Car si un user externe change par exemple sa 'catégorie' le traitement des prix et de la facturation est touché, ce que l'on ne veut pas). Par ailleurs un user 'externe' peut créer une société mais ensuite il ne peut pas la 'retrouver' et la modifier (pour ajouter un contact, un tel, ...). Un user 'externe' est aussi limité par les onglets visibles lorsqu'il 'ouvre' une société. Toutes ces limitations qui pourraient paraitre 'naturelle' (le système d'information est 'réservé' en général aux utilisateurs internes) restreignent la 'portée' que l'on peut 'étendre' de Dolibarr à ses revendeurs, apporteurs d'affaire ou même fournisseurs. L'objectif étant de considérer ces catégories de tiers comme des 'partenaires' qui utilisent Dolibarr afin d'avoir accès à une information profitable pour tous, de 'fédérer' des entreprises/individus éparpillés géographiquement ou même commercialement (un revendeur ne vend pas forcément exclusivement nos produits) et donc d'obtenir un 'esprit d'équipe' avec un outil donnant l'état de ses prospects, les produits/services disponibles et des 'sorties' (propositions) homogènes pour l'état de la société.
Il ne faudrait donc plus faire de différence entre 'interne' et 'externe' et 'recentraliser' la gestion des utilisateurs par un pilotage exclusif au niveau de l'interface d'administration.
Romain
|
|
|
|
|
|
 | | |
|
|