Remplacer par Fabrik un ERP/CRM "fait maison" ?

[RobertG]

Bonjour,

Une cliente pour qui j'interviens sur des sites Joomla! utilise depuis quelques années un système de gestion d'agents, familles d'accueil et élèves (stages de langue en immersion), solution créée par un développeur sur la base du framework Wumpa, sur une base PostgreSQL.
Wumpa n'a pas été mis à jour depuis 5 ans, il y a des erreurs PHP (non bloquantes) dès 5.6 et si je me souviens bien un essai fait il y a quelques semaines, ça plante dès 7.1 !
Etant donné que je ne suis pas développeur et que je n'ai même pas réussi à cloner le site pour tests, il n'y a que deux options : trouver un développeur pour reprendre le tout, ou passer une autre solution.

Je cherche donc si c'est possible avec Joomla! et extensions, ou une association de Joomla! avec une solution dédiée comme Dolibarr par exemple.

Il y a deux versants : un formulaire d'inscription permettant à l'élève ou sa famille de choisir la formule dans une liste, le type d'hébergement (liste), la durée de stage (x semaines du dimanche au samedi) + nuits supplémentaires si arrivée et/ou départ décalé, choix d'option et d'activité complémentaire, le tout générant un coût qui sera reporté sur une facture ; bien entendu, les informations concernant l'élève doivent être fournies.
J'imagine qu'un gestionnaire de formulaire peut répondre à ce besoin.
Cependant, la confirmation de réception au client comporte un lien direct vers une page de complément de formulaire correspondant précisément à ce postulant, sans passer par une identification. Une partie des réponses de ce nouveau formulaire dot être ajoutée aux informations précédemment enregistrées.
J'imagine là aussi qu'on pourrait unifier ces deux formulaires, la question étant ensuite de pouvoir les réutiliser dans la partie gestion du site (identité, divers choix influant sur l'affectation de l'élève à telle ou telle famille, .

Il y a donc ensuite la gestion interne de type ERP/CRM : un administrateur, des agents, des familles d'accueil, des élèves, des formules de cours, des offres complémentaires... Il faut pouvoir affecter des élèves à des agents (qui peuvent donc inscrire eux-même leurs élèves, sans passer par le formulaire précédent), les élèves aux familles, pouvoir lister les élèves par agent, pouvoir générer par simple clic sur la ligne de l'élève la facture, la commission de l'agent (variable), le paiement par les élèves et celui aux familles, avec le plus de simplicité possible.

Une famille va être assignée au postulant par l'administrateur, qu'il ait été enregistré par l'agent ou en passant par le formulaire.
L'agent peut inscrire ses propres clients, sélectionner ensuite l'élève et générer un PDF avec la facture et sa commission, fonction du choix de la formule et de certains compléments.

Avez-vous des idées à me soumettre ? Merci d'avance !
Robert

[jfque]

Pour ce genre d'application, j'utilise toujours Fabrik qui permet de faire toutes les entrées/sorties/manipulations de données nécessaires. L'avantage d'un tel composant est que c'est à la fois du "sur mesure" mais intégré dans Joomla!, donc pouvant évoluer avec le site à l'avenir.

[RobertG]

Merci de ta réponse. J'y avais pensé, mais si je l'ai utilisé un jour, c'était il y a bien longtemps, et il me semble que c'est un outil assez compliqué à mettre en oeuvre.
Ce qui m'étonne est qu'il n'y a pas eu de mise à jour depuis plus d'un an, mais peut-être est-ce normal ?

[RobertG]

Je n'avais pas tout exploré, il y a une mise à jour récente pour Joomla! 3.9.16
Mais si j'ai bien compris, installation et mises à jour ne se font que par ftp ?

[jfque]

Oui, effectivement :

• C'est une extension extrêmement puissante et, par conséquent, quelque peu difficile à maîtriser (mais c'est passionnant d'y arriver)
• C'est une des rares extension qui a été affectée par une modification intervenue dans la dernière version de Joomla!. Les développeurs travaillent dur pour sortir une version compatible avec J4 et donc il n'y a plus eu de mise à jour depuis longtemps de la version actuelle, en tout cas en tant qu'extension "installable". Il faut faire les mises à jour depuis le dépôt Github (où il y a constamment des nouvelles modifications).
  Mais il faut d'abord installer le composant avec la dernière version PUIS faire la moise à jour par FTP avec les fichiers du dépôt Github.

[RobertG]

Merci de ces précisions !
Ne le connaissant pas du tout, et compte tenu de la situation financière des entreprises actuellement, je crains que cette solution ne convienne pas.
J'y jetterai probablement un œil quand même, à titre d'information personnelle. J'ai trouvé le wiki français avec des exemples, ça devrait aider.

[RobertG]

Bonjour,

A l'aide, Jean François ! J'ai beau lire et relire le wiki, je ne comprends toujours pas comment créer dans Fabrik un formulaire à partir de rien. Dans quel ordre listes, groupes, éléments doivent-ils être créés et associés ?

Pour reprendre ce que je disais plus haut, il me faudra une table pour les agents (Ils devront être des utilisateurs Joomla!, comme dans ton tutoriel). Là, j'espère que je saurai m'y prendre, avec ajout de de champs personnalisés Joomla! ou créés dans Fabrik (dont ton tutoriel ne fait pas état).

Ensuite plusieurs tables : les familles d'accueil, les élèves, les types de stages, les différents compléments, qui, a priori, devront être créés de A à Z, et c'est là que je n'arrive pas à m'y retrouver...

Pour les tables les plus simples par exemple, j'aurai besoin, en plus de l'Id, d'un champ de définition de l'élément "stage de..." et un autre de prix qui devra ensuite être utilisé pour calculer le coût total de la réservation.

Puis-je créer des éléments comme "last name", de type "field", puis les réutiliser par exemple pour les familles et les élèves ou faudra-t-il les dupliquer ? Je n'ai pas compris le principe de la création de table qui se fait depuis la liste avant tout ajout de champs.

[RobertG]

Bonjour,

J'en suis à la création des tables de base (j'ai fini par comprendre que la séquence est Liste-->éléments .

Pour les tables simples, en fait je n'en ai créé qu'une avec un champ "type". Il n'y a pas suffisamment d'éléments pour en faire plusieurs tables à structure identique.

Pour celle des élèves, qui ne seront pas des utilisateurs, il ne devrait pas y avoir de difficultés, pas de liens entre tables.

Le problème est maintenant de comprendre comment, pour les agents et familles, qui seront des utilisateurs avec accès à leurs propres données, comment insérer le ID de la table "#__user" dans la table dédiée : dans le formulaire de création comment lier les tables pour ajouter en même temps l'utilisateur dans la table "#__user" et les données spécifiques dans la table "agents" ou "familles", sachant que cette création ne sera faite que par un administrateur (et peut-être partiellement modifiable par l'utilisateur) ?

Merci de vos conseils !

[jfque]

Oui, tout commence par la création d'une liste, et pour les tables "simples", c'est effectivement facile de les créer (ou de s'y connecter si elles existent déjà).
Pour l'ID de l'utilisateur, c'est évidemment plus compliqué et il y a plusieurs manières de faire suivant le résultat souhaité et le mode d'administration chois par la suite. C'est trop long à expliquer dans un post mais cela implique de faire une jointure entre la table #__users et la table de vos utilisateurs, avec une correspondance entre l'ID (clé primaire) de la table #__users et un élément user_id (clé secondaire) de votre table utilisateur.
Il y a également un plugin de formulaire (juser) qui permet la création d'un utilisateur Joomla! via un formulaire Fabrik. Je ne sais pas si le Wiki en français en parle mais cela se trouve sur le wiki anglais.

[RobertG]

Merci JF !

A force de tâtonnements, je crois avoir compris que pour les agents, il faudrait que je crée une liste "Agents" basée sur la table "#__users" et une autre "Agents_extrafields" liées par le champ ID de "users" et le champ "user_id" de la table des extras comme tu l'expliques dans ton tutoriel que j'avais mal interprété jusqu'ici.

[jfque]

Je suppose que vous faites référence au tutoriel que j'avais écrit il y a des années (c'était encore J! 2.5) sur mon ancien site (betterliving.be) ? Fabrik et le plugin JUser ont bien évolué depuis mais cela donne une bonne base.
La différence principale est qu'aujourd'hui, j'ai plutôt tendance à utiliser comme table "principale" la table "extra_fields" en faisant une jointure droite (right join) vers #__users, plutôt que l'inverse (table principale #__users et jointure gauche vers la table extra).
Une nouveauté toute récente dans le plugin JUser (que vous devez avoir si vous utilisez la version provenant de Github) permet aussi de synchroniser l'ID (clé primaire) de la table "extra" avec celui de la table #__users. Cela permet dès lors d'utiliser plus facilement cette table "extra" pour des jointures vers d'autres tables avec une concordance sur le user_id.

[RobertG]

En effet, je me base sur ce tutoriel fait pour la 2.5

Pour l'instant, je butte sur les droits pour l'affichage du formulaire de création d'agent par un administrateur où, par exemple, je n'arrive pas à empêcher l'affichage du champ "block" (et d'autres) malgré l'interdiction d'affichage dans la liste.
Mais les choses avancent lentement.

J'avais raté le choix de masquer les éléments dans le formulaire, mais je n'arrive pas à le faire pour "params" de la table users. Pour le reste, il va falloir d'abord tester pour valider.

[jfque]

Tous les éléments n'ont pas un réglage "caché" dans leurs paramètres. C'est le cas du champ "params" qui est un élément "textarea". Dans cette situation, il y a 2 moyens :

• soit, via phpMyAdmin, dans la table #__fabrik_elements, pour cet élément, mettre la valeur à 1 dans la colonne "hidden"
• soit modifier cet élément en "field", mettre le réglage sur "caché, sauvegarder (sans fermer), puis remettre l'élément sur "textarea" et sauvegarder et fermer. Le textarea conservera le réglage "caché"

[RobertG]

Merci de ces précisions ! J'ai fait ce masquage directement dans la base, pour éviter un double changement de type dans la table "#__user".

Mais je suis maintenant sur un autre os : j'ai défini une liste "Agents" correspondant à la table "users", puis une liste "Infos Agents" avec sa propre table qui comporte trois champs : id, date et user_id (récupéré par jointure dans la table users.
Je veux ajouter des champs (adresse, etc.) dans cette table "infos agents" qui a été créée, mais par où que je passe, lorsque je veux ajouter un élément "adresse" depuis la liste ou le groupe, j'ai ce message :

Vous ne pouvez pas ajouter de champs à cette liste

Par contre, je peux ajouter l'élément à la table "#__users", ce qui ne me convient pas.
Il faut que je reprenne tranquillement, car il est possible que ce soit lié à des mises à la corbeille de données d'essais.

[jfque]

Oui, il faut reprendre ça à tête reposée parce que ce devrait être l'inverse : ne pas ajouter/modifier de champs dans la table #__users (c'est possible, mais ce n'est pas une bonne pratique) et les ajouter dans la table extra.
L'astuce est que, une fois que la jointure est faite, vous devez ajouter vos champs dans le groupe qui se trouve dans le formulaire attaché à la liste "extra", pas dans celui lié à la liste "users".