ProxyEPN

Bonjour,

La classe 'BaseStructureGroupPeer' doit se trouver dans le dossier lib/model/om/.

Il ne fait pas partie des sources (ni sur le SVN, ni dans l'archive) car il est généré automatiquement à l'installation par Propel. Normalement cette étape est effectuée par le script rebuild.sh (./symfony propel:build-model).

Je pense qu'il y a quelques soucis avec l'archive 2.0 qui contient un bout de cache Symfony. Car si l'application se trouve dans un autre dossier, j'ai l'impression que la tache "./symfony cc" pour purger le cache échoue lamentablement... Ceci bloquerait alors l'exécution du script rebuild.sh et par conséquent la génération des classes de base.

Vous devriez donc essayer de supprimer manuellement le fichier : cache/project_autoload.cache
Ensuite relancez le script ./rebuild.sh

J'espère alors que tout sera mieux en place.

Grégory

Bonjour et merci pour votre réponse.
En effet la solution était bien là.

Par contre par la suite lorsque je veux appliquer le patch jquery_autocompleter.patch, le serveur me retourne cette erreur :
patching file web/sfFormExtraPlugin/js/jquery.autocompleter.gfm.js
Hunk #1 FAILED at 555.
1 out of 1 hunk FAILED -- saving rejects to file web/sfFormExtraPlugin/js/jquery.autocompleter.gfm.js.rej

1. ./symfony guard:create-user admin mon_mot_de_passe
   le serveur me retourne une erreur 500
   Dans mes logs PHP je trouve alors l'erreur suivante : Propel behavior "sfPropelActAsSignableBehavior" is not registered
   Si je continue avec la commande suivante :
   #./symfony guard:promote admin
   il me renvoi : l'utilisateur admin n'existe pas ...

Le fichier en pièce jointe est la sortie console du rebuild.sh au cas où l'erreur se situe à ce niveau.

Merci

Gweltaz

bonjour,

je cherche également à installer proxy epn sur une squeeze, pourrais-tu m'aider, j'ai un problème avec apache et la config du ssl ?

Bonjour,
Pour la configuration du SSL il te faut tout d'abord des certificats ...
Pour les générer tu peux le faire avec Openssl, TinyCA2, Xca. Dans le certificat que tu génère il faut que le common name (cn) corresponde au nom du virtual host sous apache.
Ensuite en suivant la configuration d'apache proposée dans le fichier INSTALL et les étapes nécessaires (dossier Doc de l'archive proxyepn-2.0) tu as toutes les indications nécessaires pour y arriver.

Si tu as d'autre problèmes poste ton httpd.conf et le httpd-ssl.conf d'apache.

Mon problème apparaît lors de la création de l'utilisateur admin ce qui fait que je ne peux pas m'identifier et donc "entrer" dans l'application, je ne sais pas si tu rencontre (rencontrera) le même problème mais en tout cas à ce niveau là tu doit être capable d'afficher l'interface de login de l'application

Bon courage !

Gweltaz

Par contre par la suite lorsque je veux appliquer le patch jquery_autocompleter.patch, le serveur me retourne cette erreur :
patching file web/sfFormExtraPlugin/js/jquery.autocompleter.gfm.js
Hunk #1 FAILED at 555.
1 out of 1 hunk FAILED -- saving rejects to file web/sfFormExtraPlugin/js/jquery.autocompleter.gfm.js.rej

Je pense que ceci est normal si vous utilisez l'archive 2.0 de proxyepn, car ce patch a déjà été appliqué sur les sources.
Ce point a d'ailleurs été amélioré dans la procédure d'installation de la prochaine version puisque le script rebuild.sh se charge de l'appliquer automatiquement en vérifiant si cela a déjà été fait ou non.
Si vous souhaitez vérifier que le patch est bien en place, vous pouvez faire par exemple : grep Marigot web/sfFormExtraPlugin/js/jquery.autocompleter.js

Et lorsque je veux ajouter mon utilisateur admin avec la commande :

1. ./symfony guard:create-user admin mon_mot_de_passe
   le serveur me retourne une erreur 500
   Dans mes logs PHP je trouve alors l'erreur suivante : Propel behavior "sfPropelActAsSignableBehavior" is not registered

Pas pratique en effet d'être bloqué à ce niveau...
J'ai effectué quelques tests qui confirment le bug, un ticket a été créé le concernant (cf #110).

Dans l'immédiat, vous pouvez toujours éviter l'erreur le temps de créer votre compte admin, en commentant la dernière ligne du fichier /lib/model/sfGuardUserProfile.php :

#sfPropelBehavior::add('sfGuardUserProfile', array('sfPropelActAsSignableBehavior' => array()));

Super !

Merci beaucoup j'ai pu créer mon utilisateur et me logguer dans l'appli.

Par contre lorsque j'ai voulu ajouter un groupement d'EPN, lors de l'enregistrement de l'occurence j'ai beau renseigner la ville celle-ci n'est pas prise en compte. Il efface mon entrée et marque "Champ Requis". là ça semble être au niveau du post de la page que ça coince ...

J'ai donc eut une grande joie mais de courte durée car si je ne peux pas entrer de GEPN je ne peux entrer d'EPN...

La sortie de la nouvelle version est prévue quand ?

Cordialement,

Gweltaz

Merci pour ton aide, les certificats sont générés et j'arrive sur la page d'accueil de proxyepn.
Je suis arrivé au moment de créer l'utilisateur admin et j'ai la même erreur 505 qui apparait...

Peux-tu me dire ou tu vois tes log PHP ?

Merci.

Romain

Par contre lorsque j'ai voulu ajouter un groupement d'EPN, lors de l'enregistrement de l'occurence j'ai beau renseigner la ville celle-ci n'est pas prise en compte. Il efface mon entrée et marque "Champ Requis". là ça semble être au niveau du post de la page que ça coince ...

La saisie de la ville n'est pas un champs libre : normalement il y a une auto-complétion via ajax (une fois la ville sélectionnée c'est d'ailleurs son code INSEE qui est enregistré dans la BdD).

• vois-tu la recherche Ajax se lancer (à partir de 2 caractères dans le champs) ? une icone d'attente doit s'afficher à droite du textfield
• si oui, obtiens-tu des réponses (une liste déroulante doit apparaitre sous le texfield) et en as-tu sélectionné une ?
• si non, la table 'insee_town' a-t'elle bien été peuplée ? le fichier /data/fixtures/proxyepn-insee.sql contient normalement toutes les localités françaises

La sortie de la nouvelle version est prévue quand ?

Il n'y a pas encore de date prévue, entre autre car la liste des modifications qui en feront partie ou pas n'est pas encore définie.
Mais ce sera normalement dans un délai relativement court, disons quelques semaines... Je ne souhaite pas trop retarder la venue des quelques évolutions et corrections prévue, même si pour cela d'autres modifications plus couteuses en temps de developpement devront attendre la version suivante.

Sinon il est également envisageable d'utiliser la version SVN qui généralement est plutot stable... Le site de démo est régulièrement synchronisé avec le SVN. C'est également la dernière version SVN que nous utilisons en production, évidement c'est bien plus simple pour moi de savoir qu'elle est fonctionnelle et quels sont les changements appliqués...

Je vais d'ailleurs ajouté sur le SVN quelques infos concernant les procédures de mise à jour de l'application.

L'autocomplétion ne se fait pas. ma table est bien peuplée.

Est-ce que le patch que j'ai appliquer à tort ne peux pas créer ce bug ?

Merci

Gweltaz

L'autocomplétion ne se fait pas. ma table est bien peuplée.

Est-ce que le patch que j'ai appliquer à tort ne peux pas créer ce bug ?

C'est possible en effet, si le patch a été forcé, le code n'est sans doute plus valide... et il concerne bien le widget d'auto-complétion.

Il suffit alors de remettre le fichier d'origine de l'archive (web/sfFormExtraPlugin/js/jquery.autocompleter.js)

PS: Une doc est maintenant disponible sur le SVN concernant la mise à jour de l'application.

J'ai le même problème que Gweltaz.
J'ai bien remplacé le fichier jquery.autocompleter.js comme indiqué précédemment mais toujours pas d'auto-complétion dans le champ ville. :-(

Rom@in

Anonyme a écrit :

J'ai le même problème que Gweltaz.
J'ai bien remplacé le fichier jquery.autocompleter.js comme indiqué précédemment mais toujours pas d'auto-complétion dans le champ ville. :-(

Rom@in

Bizarre...
Aucune trace d'erreur PHP dans les logs d'apache ?
Aucune erreur Javascript dans la console du navigateur ?

Normalement le code source HTML de la page du formulaire doit contenir ceci dans ses entêtes :

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/javascript" src="/js/../sfFormExtraPlugin/js/jquery.autocompleter.js"></script>

Plus loin le code du champs texte doit ressembler à ceci :

<input size="40" class="required" type="text" name="autocomplete_structure_group[code_insee]" value="" id="autocomplete_structure_group_code_insee" /><script type="text/javascript">
  jQuery(document).ready(function() {
    jQuery("#autocomplete_structure_group_code_insee")
    .autocomplete('/insee_town/ajaxSearch', jQuery.extend({}, {
      dataType: 'json',
      parse:    function(data) {
        var parsed = [];
        for (key in data) {
          parsed[parsed.length] = { data: [ data[key], key ], value: data[key], result: data[key] };
        }
        return parsed;
      }
    }, { minChars:2, scroll:1 }))
    .result(function(event, data) { jQuery("#structure_group_code_insee").val(data[1]); })
    .keyup(function() {
      if(this.value.length == 0) {
        $('#structure_group_code_insee').val('');
      }
    });
  });
</script>

J'ai testé en réinstallant l'appli depuis l'archive de la version 2.0, et je n'ai pas rencontré de problème au niveau de l'autocomplétion.

• Dans le fichier apps/frontend/modules/insee_town/actions/actions.php, il faut d'abord commenter la ligne 80
  $this->forward404Unless($request->isXmlHttpRequest());
• Puis depuis votre navigateur, interrogez directement l'url /insee_town/ajaxSearch?limit=10&q=mar
  Une liste des villes contenant "mar" devrait alors vous être retournée.

Bonjour,

je viens de trouver l'erreur qui empéchait l'auto-complétion :

dans mon dossier web/js, j'ai un fichier jquery-1.5.2.js alors que celui appelé par l'appli est jquery.js (pourquoi, je ne sais pas !)

J'ai donc renommé mon fichier jquery-1.5.2.js en jquery.js et cela fonctionne désormais.

Par contre, j'ai un fichier jquery-1.5.2.min.js, dois-je aussi le renommé en jquery.min.js ?

Cordialement

Rom@in

Par contre nouveau bug, une fois les renseignements mis pour créer un egpn, quand je fais "enregistrer", je tombe ensuite sur une page blanche :-(

Anonyme a écrit :

dans mon dossier web/js, j'ai un fichier jquery-1.5.2.js alors que celui appelé par l'appli est jquery.js (pourquoi, je ne sais pas !)
J'ai donc renommé mon fichier jquery-1.5.2.js en jquery.js et cela fonctionne désormais.
Par contre, j'ai un fichier jquery-1.5.2.min.js, dois-je aussi le renommé en jquery.min.js ?

Bonjour,

C'est bien le nom court "jquery.js" qui est appelé dans le code, de même pour "jquery-ui.js" d'ailleurs. Dans le dossier web/js/ ce sont normalement des liens symboliques vers les fichiers correspondant avec numéros de version.

Les liens sont bien définis dans l'archive, peut-être avez-vous eu un problème en la décompressant ou en transférant les fichiers qui aurait mal géré les liens symboliques ? A vérifier, car si c'est le cas d'autres liens ont pu être affectés, par exemple : web/sf, web/sfFormExtraPlugin, web/sfPropelPlugin, web/css/ui-proxyepn/jquery-ui.css

Concernant les versions 'min', il s'agit des fichiers "compressés" pour améliorer le chargement des scripts externes. Ils sont donc à utiliser de préférences (les liens jquery.js et jquery-ui.js pointent normalement sur les versions 'min') mais rien de grave à utiliser les versions normales, à part un poid des fichiers un peu plus gros.

Anonyme a écrit :

Par contre nouveau bug, une fois les renseignements mis pour créer un egpn, quand je fais "enregistrer", je tombe ensuite sur une page blanche :-(

Pas de soucis de mon coté... Une page blanche cela ressemble à une erreur au niveau du code PHP : les logs d'erreur de votre serveur web devraient pouvoir nous en dire plus.

Bonjour,
j'ai réinstallé complètement proxyEPN. Effectivement en décompressant l'archive sur le bureau et en la transferant via FTP sur le serveur les liens symboliques ne sont pas recopiés. Je n'ai pas eu ce problème avec un tar direct sur le serveur.

A partir de la l'autocomplétion se fait bien dans le champ Ville.
Par contre, comme Romain après avoir valider le GEPN j'ai une page blanche.

Je n'ai aucune trace dans les logs PHP
Voici les logs trouvé dans le fichier log/frontend_dev.log :
Jun 24 17:42:50 symfony [info] {sfPatternRouting} Connect sfPropelRoute "sf_guard_group_delete" (/sf_guard_group/:id.:sf_format)
Jun 24 17:42:50 symfony [info] {sfPatternRouting} Connect sfPropelRoute "sf_guard_group_show" (/sf_guard_group/:id.:sf_format)
Jun 24 17:42:50 symfony [info] {sfPatternRouting} Connect sfPropelRoute "sf_guard_group_object" (/sf_guard_group/:id/:action.:sf_format)
Jun 24 17:42:50 symfony [info] {sfPatternRouting} Connect sfPropelRoute "sf_guard_group_collection" (/sf_guard_group/:action/action.:sf_format)
Jun 24 17:42:50 symfony [info] {sfPatternRouting} Match route "gepn_action" (/gepn/:action/*) for /gepn/create with parameters array ( 'module' => 'structure_group', 'action' => 'create',)
juin 24 17:42:50 symfony [info] {sfFilterChain} Executing filter "sfRenderingFilter"
juin 24 17:42:50 symfony [info] {sfFilterChain} Executing filter "sfGuardRememberMeFilter"
juin 24 17:42:50 symfony [info] {sfFilterChain} Executing filter "sfSslRequirementFilter"
juin 24 17:42:50 symfony [info] {sfFilterChain} Executing filter "sfExecutionFilter"
juin 24 17:42:50 symfony [info] {structure_groupActions} Call "structure_groupActions->executeCreate()"

Donc seulement des logs d'info pas d'erreur à priori ...

En voulant recharger la page blanche j'obtiens à ce moment l'erreur suivant dans mes logs PHP
[24-Jun-2011 17:42:57] This request has been forwarded to a 404 error page by the action "structure_group/create".

Je vais essayer la version SVN la semaine prochaine pour voir si on a les mêmes problèmes.

@ Romain : Les logs PHP tu les configure dans ton php.ini.
Tu peux les laisser dans syslog ou bien configurer la directive error_log

Merci Gweltaz

J'ai peut-être une idée... à essayer en tout cas !

Dans le fichier "apps/frontend/config/app.yml" il semble que l'export LDAP soit activé par défaut. Mais fatalement il a toute les chances d'échouer en l'état ! Cela qui me donne une page d'erreur 500 chez moi, mais il est probable que ce soit le même soucis pour vous.

Donc il suffit de spécifir "enabled: false" dans la section "ldap_export" du fichier. J'aurais dû mettre ainsi par défaut et je vais d'ailleurs rectifier le fichier sur le SVN de ce pas. Ensuite à la racine du site, nettoyer le cache de Symfony pour que les fichiers de conf soient rechargés en tapant : ./symfony cc

Je vais essayer la version SVN la semaine prochaine pour voir si on a les mêmes problèmes.

Utiliser la version SVN reste une bonne idée d'après moi, aussi bien pour profiter des dernières corrections et évolutions, que pour la simplicité de mise à jour de l'application.

Pour créer sa copie locale :

svn co http://svn.proxyepn.org/repos/proxyepn/proxyconcept/trunk .
(suivre ensuite doc/INSTALL pour la configuration initiale)

Puis pour la mettre à jour :

svn update
(regarder s'il y a des modifications dans data/fixtures/proxyepn-update-2.1.sql)
./rebuild.sh

En général le trunk reste fonctionnel. Bien sûr je ne peux garantir que ce sera toujours le cas, mais c'est ce qui est souhaité. Cependant si l'application est utilisée en production, une démarche prudente consiste à déployer une version de test en parallèle, permettant de vérifier que l'update ne casse rien avant de l'appliquer en prod.

La principale attention lors d'un update est de surveiller d'éventuelles modifications à apporter dans la base de données, d'où la note sur le fichier proxyepn-update-2.1.sql que je tiens à jour dès que nécessaire.

Il est bon aussi d'observer si l'update impacte des fichiers modifiés localement. Cette situation est à priori assez rare, cela concernerait en général les quelques fichiers de configuration que vous avez personnalisé.

Bonjour et merci pour vos réponses.

alors me concernant, le fait de mettre "export ldap enabled" à "false" à résolu le problème de page blanche pour la création des GEPN et EPN.

Par contre maintenant que l'application est OK, on gère les usagers, les EPN, les sessions... mais je me pose la question de son utilisation pour filtrer les accès des usagers, donner des droits, etc, ... Est-ce possible ?

Cordialement,
Rom@in

Bonjour, effectivement c'est bien la tentative d'export vers LDAP qui causait le problème

J'ai fait quelques tests par la suite et je n'ai pas détecter d'autres problèmes.

Je passe à la version SVN cette après midi.

Merci pour votre aide

Gweltaz

Anonyme a écrit :

Par contre maintenant que l'application est OK, on gère les usagers, les EPN, les sessions... mais je me pose la question de son utilisation pour filtrer les accès des usagers, donner des droits, etc, ... Est-ce possible ?

ProxyEPN n'effectuera pas de filtrage, ce n'est qu'une application web. Pour filtrer les accès il faut déployer d'autres dispositifs, au niveau d'un firewall par exemple, généralement avec un portail captif pour gérer les authentifications.

Par contre ProxyEPN peut représenter un bon complément à ce genre de solution en procurant l'interface permettant de gérer les comptes usagers. C'est d'ailleurs dans ce but que l'export LDAP est disponible : ProxyEPN permet d'alimenter un annuaire LDAP qui est ensuite utilisé comme base d'authentification par les dispositifs filtrants.