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.

[PeytaWodka]

C'est pour ça que je dis surcharger la méthode executeConfirm et au lieu d'activer l'utilisateur, envoyer les différents mails etc.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
  public function executeConfirm(sfRequest $request)
  {
    $validate = $this->request->getParameter('validate');
    // 0.6.3: oops, this was in sfGuardUserProfilePeer in my application
    // and therefore never got shipped with the plugin until I built
    // a second site and spotted it!
 
    // Note that this only works if you set foreignAlias and
    // foreignType correctly
    $sfGuardUser = Doctrine_Query::create()
        ->from("sfGuardUser u")
        ->innerJoin("u.Profile p with p.validate = ?", $validate)
        ->fetchOne();
    if (!$sfGuardUser)
    {
      return 'Invalid';
    }
    $type = self::getValidationType($validate);
    if (!strlen($validate))
    {
      return 'Invalid';
    }
    $profile = $sfGuardUser->getProfile();
    //clearing validate and validate_at fields
    $profile->setValidate( null );
    $profile->setValidateAt( null );
    $profile->save();
    if ($type == 'New')
    {
      //$this->activateUser( $sfGuardUser );
      // envoyer mail au modérateur
      // envoyer mail à l'utilisateur
    }
    if ($type == 'Reset')
    {
      $this->getUser()->setAttribute('sfApplyReset', $sfGuardUser->getId());
      return $this->redirect('sfApply/reset');
    }
    if( $type == 'Email' )
    {
      if( sfConfig::get( 'app_sfForkedApply_mail_editable' ) )
      {
        $profile->getUser()->setEmailAddress( $profile->getEmailNew() );
        $profile->setEmailNew( null );
        $profile->save();
        $this->getUser()->setFlash( 'sf_forked_apply',
            sfContext::getInstance()->getI18N()->
            __( 'Your email has been changed.',
                array(), 'sfForkedApply' ) );
        return $this->redirect( '@homepage' );
      }
      return 'Invalid';
    }
  }

[Michel Rotta]

Tu ne peux pas surcharger juste une méthode. Tu as plusieurs actions et interventions et traitement différents. Il faut donc rajouter des actions, des traitements et des écrans. Beaucoup pour la seule modification d'une méthode.

A partir de là, et sans être sur que la table du sfFDAP va convenir aux nouveaux traitements, il me semble qu'envisager d'écrire un module adapté n'est pas nécessairement une mauvaise idée.

[Mordri]

Merci pour vos réponses et désolé pour la mienne un peu tardive.

la méthode que propose PeytaWodka semble plus facile à réaliser dans l'immédiat. Le problème est que je n'ai pas énormément de temps pour refaire un plugin, ensuite j'utilise sfFDAP aussi pour ajouter des champs à mes utilisateurs donc j'ai pas envi de tout refaire sans sfFDAP.

Sinon pour que l'admin change le statut j'ai déjà créer les actions, j'ai justes à envoyé un petit mail de confirmation pour l'utilsateur à ce moment la