Discussion :

[Mordri]

Bonjour,

Voila j'ai installer sfForkedDoctrineApplyPlugin tout marche nickel (enfin j'ai pas encore testé les emails pour l'instant) mais j'ai plusieurs questions :

Comment faire pour que l'activation ne se fasse que par un super admin? c'est à dire que je voudrais que la personne s'inscrivant ne puisse pas s'activer elle même.

J'aimerai cependant qu'un email lui disant d'attendre qu'un admin l'active lui soit envoyer, et j'aimerai envoyé un email à tous les admins pour leurs prévenir qu'un membre veut s'inscrire (c'est un outil en intranet alors pas de soucis au niveau du spam normalement)

Pour l'instant j'ai désactiver la confirmation par email mais l'utilisateur est de suite activer, même en surchargeant la methode save() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
//lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php
public function save(Doctrine_Connection $conn = null)
  {
    if($this->isNew()) $this->setIsActive(false);
    parent::save($conn);
  }

[PeytaWodka]

J'ai une partie de la solution :
Tu crée un backend avec un module pour les utilisateurs et tu ajoutes les actions Activé et Désactivé.

Pour empêcher l'activation, je ne sais pas comment faire.

[Mordri]

J'ai déjà réalisé ça pour activer et désactiver, j'en ai même fait pour passer quelqu'un en super admin.

Mon gros problème est justement d’empêcher cette activation automatique :/

[Michel Rotta]

Le problème est que sfFDAP est conçu initialement pour permettre à un user de se créer un compte et de l'activer seul et automatiquement.

Il me semble que la meilleur solution serait de ne pas utiliser sfFDAP et de construire un outil qui te convienne. Rien n’empêche de t'inspirer de sfFDAP pour les traitements à mettre en oeuvre. Par contre, ils (les traitements) sont trop différents de ceux de sfFDAP pour qu'un simple fork ait une chance de marcher sans ressembler à une usine à verrues.

[PeytaWodka]

Sans vouloir forcer les choses, il suffit de commenter une ligne dans le plugin pour ne pas activer un utilisateur lors de la confirmation par email ou mieux surcharger la méthode executeConfirm du module sfApply.
Je suis d'accord que ça entraîne des problèmes en cas de mis à jour du plugin mais c'est toujours plus rapide que de réinventer la roue non ?

[Michel Rotta]

Mais ainsi tu ne génères pas le message qui averti qu'un modérateur va intervenir. Ni celui aux modérateur d'intervenir. Ni celui à l'utilisateur pour l'informer que le compte est créé. Ni l'écran qui permet au modérateur d'accéder aux non validés. Ni le champs dans la table qui indique qu'il est en attente de validation du modérateur... Un simple point virgule ne me semble pas suffisant.