ProxyEPN

Bonsoir,
après quelques heures pour coder la passerelle, je teste et j'ai cette erreur:

Fatal error: Call to undefined function format_phone() in /var/www/proxyepn/lib/model/sfGuardUserProfile.php on line 172

es-ce lié au fait que je soit partis de la version 2.1 et non du SVN complet ?

Pour faire simple: j'ai pris la version 2.1 et j'ai ensuite pioché les deux scripts indiqués. Je vais creuser un peu mais c'est pour faire un feedback rapide :)

Merci encore,
Éric

Pour palier temporairement au problème indiqué j'ai juste ajouté la ligne suivante dans proxyepn/lib/model/sfGuardUserProfile.php

include("lib/helper/ProxyepnHelper.php");

Je lance mon export/import et vous tiens au courant.

Éric

Les tâches de Symfony sont parfois assez succeptibles... J'avais en effet déjà dû rajouter le chargement du helper. Mais ici étrangement, cela fonctionne chez moi sans avoir à le spécifier...

Enfin bref je l'ai remis (r525) : je place plutot l'include en question dans lib/task/proxyepnUserCreateTask.class.php plutot que lib/model/sfGuardUserProfile.php

Cela devrait résoudre tout problème, en tout cas je l'espère.

Nouvelle modification r526 : j'ai décommenté la ligne contenant l'include, c'est mieux...

Bonjour,

un rapide retour après quelques jours d'utilisation: impec, tout marche bien.

Merci encore,
Éric

Modifications publiées sur le svn (r544) :

Pour compléter le script de création d'usager et suite à ce message d'Eric Seigne sur le forum : [résolu] Interface CLI pour mise à jour de compte utilisa... , une nouvelle tâche Symfony nommée proxyepn:user-update permet de modifier un compte usager depuis la ligne de commande.

# ./symfony help proxyepn:user-update
Usage:
 symfony proxyepn:user-update [--application="..."] [--env="..."] [--connection="..."]
 [-v|--verbose] [-T|--test] [--epn[="..."]] [--lastname[="..."]] [--firstname[="..."]]
 [--birthday[="..."]] [--sex[="..."]] [--username[="..."]] [--password[="..."]]
 [--expire[="..."]] [--profile[="..."]] [--title[="..."]] [--email[="..."]]
 [--phone1[="..."]] [--phone2[="..."]] [--insee[="..."]]
 [--postal[="..."]] [--town[="..."]] [--address[="..."]] id

Arguments:
 id             Id ou référence de la fiche usager

Options:
 --application  The application name (default: frontend)
 --env          The environment (default: prod)
 --connection   The connection name (default: propel)
 --verbose      (-v) Enables verbose output
 --test         (-T) Test only - no action
 --epn          Id de l'EPN d'origine
 --lastname     Nom de l'usager
 --firstname    Prénom de l'usager
 --birthday     Date de naissance
 --sex          Sexe de l'usager ( M | F )
 --username     Identifiant de connexion
 --password     Mot de passe de l'usager
 --expire       Date d'expiration du compte
 --profile      Id du profil d'accès Internet
 --title        Titre ( M. | Mme | Mlle )
 --email        Adresse email de l'usager
 --phone1       Numéro de téléphone principal
 --phone2       Numéro de téléphone secondaire
 --insee        Code INSEE de la localité
 --postal       Code postal de la ville
 --town         Nom de la ville
 --address      Complément d'adresse

Description:
 The proxyepn:user-update task update an existing user's account.
 You must specify the account to update either by database id or user's reference.
 The locality should be indicated by INSEE code or could be guessed with town and/or postal code.

 Call it with:

     php symfony proxyepn:user-update

Bonsoir,
juste une petite remarque qui est peut-être liée à mon installation, l'option --quiet ne semble pas marcher lorsque j'utilise la tâche user-update: j'ai systématiquement ceci

>> sfPatternRouting Connect sfPropelRoute "sf_guard_user" (/sf_guard_user.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_new" (/sf_guard_user/new.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_create" (/sf_guard_user.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_edit" (/sf_guard_user/:id/edit.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_update" (/sf_guard_user/:id.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_delete" (/sf_guard_user/:id.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_show" (/sf_guard_user/:id.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_object" (/sf_guard_user/:id/:action.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_user_collection" (/sf_guard_user/:action/action.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group" (/sf_guard_group.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_new" (/sf_guard_group/new.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_create" (/sf_guard_group.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_edit" (/sf_guard_group/:id/edit.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_update" (/sf_guard_group/:id.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_delete" (/sf_guard_group/:id.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_show" (/sf_guard_group/:id.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_object" (/sf_guard_group/:id/:action.:sf_format)
>> sfPatternRouting Connect sfPropelRoute "sf_guard_group_collection" (/sf_guard_group/:action/action.:sf_format)
>> sfPatternRouting Match route "homepage" (/) for / with parameters array (  'module' => 'default',  'action' => 'index',)
>> myUser Add credential(s) "LIST_STRUCTURE_GROUP" 
>> myUser Add credential(s) "SHOW_STRUCTURE_GROUP" 
>> myUser Add credential(s) "LIST_STRUCTURE" 
>> myUser Add credential(s) "SHOW_STRUCTURE" 
>> myUser Add credential(s) "LIST_SESSION" 
>> myUser Add credential(s) "visitor" 

C'est peut-être lié à un truc chez nous mais je signale au cas-ou.

Pour le reste ça marche très bien, merci encore !

Éric

Eric Seigne a écrit :

juste une petite remarque qui est peut-être liée à mon installation, l'option --quiet ne semble pas marcher lorsque j'utilise la tâche user-update: j'ai systématiquement ceci

J'ai déjà vu ce genre de sortie en exécutant des taches, il me semble que celà dépend de l'environnement symfony utilisé et qu'il s'agit d'infos de debuggage du mode 'dev'.

Essayez en précisant l'option '--env=prod' et ces infos ne devraient plus apparaitre.

D'ailleurs pour éviter ce genre de soucis/oubli, j'ai modifié l'ensemble des scripts il y a environs une semaine (cf r538) pour qu'ils soient configurés par défaut avec l'environnement 'prod' au lieu de 'dev'.

Rapé, je suis déjà en env=prod ... mais je verrais plus tard pour avoir plus de détails :)

Eric Seigne a écrit :

Rapé, je suis déjà en env=prod ... mais je verrais plus tard pour avoir plus de détails :)

Sans doute encore un bug typique des tâches de symfony... J'ai déjà remarqué qu'elles étaient très capricieuses, en particulier quand il s'agit d'exploiter l'environnement général du projet (y compris des soucis avec le cache, les chemin des classes et leurs priorités, l'usage d'extensions...).

Comme le paramètre env=prod a été modifié récemment, peut-être qu'un nettoyage du cache (./symfony cc) serait utile pour les remettre dans le droit chemin... Personnellement je suis devenu bête et méchant et j'ai pris l'habitude d'exécuter le script ./rebuild.sh après chaque update des sources.

En espérant ne pas lire en réponse "Rapé, j'avais déjà fait un rebuild" ;')