Ce topic ne concerne pas les modules comme l'a déjà fait remarquer King.

Si tu souhaites travailler sur le projet workflow, prends contact avec pemen le responsable du projet, en lui indiquant tes niveaux de compétences. (Tu as de la chance, il comprend le français)

Et ce serait possible une connexion automatique sans psaser par les hacks ?

Une petite idée comme une autre : intégrer la liste des membres qui n'ont pas encore cliqué sur leur lien d'activation sur la première page de l'admin, avec la possiblilité soit de les activer, soit de supprimer le compte.

volubillis :
ca c'est fesable ac un pti module block

sinon en codant un module je me suis apercu qu'on ne peut récupérer les options d'un module quand on est sur une page d'un autre module (exemple : un block ne peut récupérer les options du module parent, si il est affiché sur un autre module)

c'est assez embetant..

Salut King76,

Vu sur le site wri (ephemere, c'est moi !) et peut-être à suivre, c'est interessant car ils connaissent xoops mais n'en sont à priori pas satisfait => améliorations possibles.
(c'est ici)

Je rejoins pas mal de point de vue, l'intégration du support du multilangue serais un plus pour l'avenir.
De plus en plus de site, notament portail, vise un public varié et à l'heure de l'internationalisation ce support en natif deviens indispensable!

Encore un malaise, un signe de plus du mauvais état de santé de Xoops,

> Discussion sur Xoops.org : voilà à mon avis ce qui ne vas aider le diagnostique de notre cher Xoops.

Xoops est malade dans son code, malade dans son esprit, xoops perd ses cellules... son humanité... depuis plus de deux ans de greffes, c'est le rejet!

Xoops manque de transparence, d'organismes fonctionnels, Xoops vit avec un coeur malade, un poumon absent et un foie inexistent!

Déjà vu, pour ceux qui se souviennent, sur phpnuke et postnuke! Le résultat sera surement le meme...

L'institutionnalisation du projet n'était pas nécessaire; le secretisme a engendré un cancer depuis bien longtemps. Il faut à present et avant que le malheur ne se propage, faire recours à l'amputation et la chimioterapie pour preserver des zones spécifiques, sites de production pour la sauvegarde de l'être avenir!


J'espère !

P.S. Vos dons n'en feront rien !
Si quelqu'un se noye, vous lui tendez un billet argenté ou plutot la main !?

Bonjour,

L'utilisation typique d'un intranet/extranet dans une entreprise passe par une identification des différents utilisateurs (ou Persones).
On peux avoir plusieurs groupes :
- Employés
- Fournisseurs
- Clients
Les employé travaillant en intranet, les fournisseurs et les clients ont leur extranet voir internet s'ils sont non inscrits.

Une personne peut être morale avec une raison social ou physique avec un nom et prénom. Elle possède au moins une adresse.
Chaque groupe possède ses propres informations. Par exmeple, l'employé controle son nombre de jour de congés restant et son RIB. Le fournisseur, son Chiffre d'affaire, le client son adresse de livraison.

Aujourd'hui Xoops ne gére pas cela directement. L'inscription est comporte des informations relative à la communication par internet plutôt des information identifiant des personnes.

Une évolution possible pour permettre la saisie des information par l'utilisateur lui-même serait de demander à l'utilisateur lors sa demande de login le role qu'il demande.
Lors d'une seconde passe, l'utilisateur devra pour être connecté avoir defini un certain nombre de donnée pour entrée dans xoops.

Coté implementation on peux :
- soit developper un module avec des tables personnes, employé et autres fournisseurs clients en dur pour un besoins standard et faire les hacks necessaires du kernel. L'avantage est de nommer les attributs et d'avoir un BD clair et exploitable facilement par des outils de reporting.
- soit developper cela dans le kernel en utilisant une table personne à double detente (c'est à dire avec des meta données) permettant à l'administrateur de définir pour chaque role un ensemble de (nom,type de données) qu'il veux utiliser pour chacun des roles. Le developeur aura des services tel que $xoopsUser->getData('nomDonnee) ou $xoopsUser->getForm('monRole');.

What do think about ?

Une autre évolution serait de developper un nouvel element de formulaire basé sur le modèle objet de xoops.

- Un xoopsSelectForeignKey faisant référence à une table de particulaire (classification par exemple) en utilisant la méthode getObject (qu'il faut au passage mettre dans l'interface).

Cela permettrait de s'abstraire des xoopsSelectMember, xoopsSelectTruc et xoopsSelectMachin qui ne sont pas très générique.

Bon c'est juste une suggestion.

Je me réveille maintenant.

Pour mes chers amis roi du code de xoops et autres, serait-il possible via un fichier log d'enregistrer les modifications apportées à un site, je pense par exemple à :
- modif des préférences de xoops,
- ajout de modules,
- ajout de catégories ou forums des modules,
- etc....

Merci de la réflexion


et peut-être pour une solution !!!

:ola: